Scrapy CrawlSpider 适合爬哪些网站？

直接答案

CrawlSpider 是 Scrapy 里用规则自动跟链接的 Spider，适合网站结构清楚、链接规律稳定、需要从列表页一路爬到详情页的场景。它的核心是 Rule 和 LinkExtractor：前者定义“哪些链接要跟、用哪个回调处理”，后者负责从页面里提取符合条件的链接。普通 Spider 更像你手写路线图，CrawlSpider 更像给爬虫装了导航规则。它能减少重复代码，但也更容易因为规则写得太宽，把不该爬的登录页、搜索页、标签页甚至日历页一起卷进去。

python
from scrapy.linkextractors import LinkExtractor
from scrapy.spiders import CrawlSpider, Rule

class NewsSpider(CrawlSpider):
    name = "news"
    allowed_domains = ["example.com"]
    start_urls = ["https://example.com/news/"]
    rules = (
        Rule(LinkExtractor(allow=(r"/news/page/\d+/",)), follow=True),
        Rule(LinkExtractor(allow=(r"/news/\d+\.html",)), callback="parse_article", follow=False),
    )

    def parse_article(self, response):
        yield {"title": response.css("h1::text").get(), "url": response.url}

使用 CrawlSpider 时不要覆盖 parse()，因为它被内部规则系统使用。需要解析详情页就写 parse_article 这类自定义回调，并在 Rule 里指定 callback。规则越精确，爬虫越可控；规则越宽，开发越省事，但队列失控、重复抓取和误入无效页面的概率也越高。生产里最好配合 allowed_domains、深度限制、去重日志和 URL 采样检查一起用。

追问

CrawlSpider 和普通 Spider 怎么选？

如果网站路径固定、你只需要列表页翻页和详情页解析，CrawlSpider 会更省代码。若流程依赖复杂参数、登录状态、多接口组合，普通 Spider 通常更清晰。CrawlSpider 的优势是自动发现链接，代价是规则调试成本更高。边界很简单：链接结构能用正则稳定描述，就可以考虑 CrawlSpider；每一步都要业务判断，就别硬套。

Rule 里的 follow 到底是什么意思？

follow=True 表示这个规则匹配到的页面下载后，还会继续从响应里提取新链接。follow=False 则通常用于详情页，只解析数据，不再从详情页继续扩散。踩坑点是详情页如果误设成 follow=True，页面里的推荐文章、广告链接、标签链接可能继续扩散，队列会变得很脏。取舍上，列表、分类、分页可以 follow，详情、附件、用户页一般不要 follow。

LinkExtractor 的 allow 和 deny 应该怎么写？

allow 用来圈定你想要的 URL 模式，deny 用来排除明显不需要的路径。规则不要写得只看“能匹配”，还要看后续维护者能不能看懂。比如 /news/\d+\.html 比一个巨长的通配正则更安全，也更容易排查。常见坑是忘了排除 ?reply=, #comment, /login 这类链接，结果爬虫在无价值页面里打转。

为什么不应该覆盖 CrawlSpider 的 parse 方法？

CrawlSpider 的 parse 已经承担了按 Rule 分发响应、提取链接、生成后续请求的职责。你覆盖它之后，规则系统可能直接失效，表现为 start_urls 能访问，但后续链接不再跟进。正确做法是写新的回调函数，比如 parse_item、parse_article，再在 Rule 里引用。这个坑很常见，因为普通 Spider 里大家习惯写 parse，迁移到 CrawlSpider 时容易顺手复制旧代码。

如何防止 CrawlSpider 爬过界？

先设置 allowed_domains，再把 LinkExtractor 的 allow 写窄，不要只依赖域名限制。其次配置深度、下载延迟和并发，避免规则失控时给目标站造成压力。上线前抽样打印命中的 URL，确认分页、详情、排除路径都符合预期。对于大型站点，建议先跑小范围分类页，验证规则后再扩大入口，否则一次错误规则就可能制造几十万条无效请求。

CrawlSpider 还适合做“半自动发现链接”的任务：你知道大概范围，但不想手写每一种分页入口。上线前可以先把 callback 里只打印 URL，不写库也不下载大文件，观察几百个命中的链接是否符合预期。规则稳定后再打开 item 解析和持久化，这一步能省掉很多返工。对内容站来说，CrawlSpider 的收益很明显；对搜索结果页、筛选页特别多的站点，规则必须保守，否则参数组合会把队列撑爆。

如果网站有多语言、多地区或移动端路径，CrawlSpider 的规则最好显式写出允许范围。不要只写 allow=(r"/article/",) 就上线，因为相似路径可能包含预览页、打印页、AMP 页和评论页。重复内容多时，Scrapy 的请求去重只能处理 URL 级重复，正文级重复还要靠业务字段或内容哈希。这个边界分清楚，CrawlSpider 才会从“自动乱爬”变成可靠的站内采集工具。

最后，别把 CrawlSpider 当成反爬解决方案。它只是链接发现和请求调度的封装，并不会自动处理登录、验证码、限速或动态渲染。遇到需要登录的站点，仍然要先完成会话管理；遇到 JS 渲染内容，也要决定抓接口还是接浏览器。把这些能力拆开设计，规则负责找路，回调负责解析，中间件负责通用请求问题，项目会更容易维护。