Scrapy 项目怎么写才更稳定？有哪些最佳实践？

Scrapy 最佳实践先从边界开始

Scrapy 项目最怕一开始跑得很快，过两周却没人敢维护。稳定的爬虫不是靠把并发拉满，而是把抓取边界、请求节奏、数据结构和失败处理提前定好。尤其是面向线上站点时，robots.txt、下载延迟、并发数和重试策略不是装饰配置，它们决定项目能不能长期运行。

一个比较稳的起步配置可以这样写：

python
ROBOTSTXT_OBEY = True
CONCURRENT_REQUESTS = 16
CONCURRENT_REQUESTS_PER_DOMAIN = 4
DOWNLOAD_DELAY = 0.5
AUTOTHROTTLE_ENABLED = True
AUTOTHROTTLE_TARGET_CONCURRENCY = 2.0
LOG_LEVEL = "INFO"
USER_AGENT = "mycrawler/1.0 (+contact@example.com)"

这里没有万能数字。新闻站、文档站、电商站承压能力完全不同，最佳实践不是照抄参数，而是先用小流量观察响应时间、错误码和封禁情况，再逐步调大。很多“爬虫不稳定”的问题，其实是没有灰度过程。

数据层也要尽早规范。Item 字段最好明确含义，pipeline 负责校验、去重和入库，spider 只做页面解析。把清洗逻辑写满 spider 的短期效率很高，但字段一多，后面改一次规则要翻十几个回调函数。

python
ITEM_PIPELINES = {
    "myproject.pipelines.ValidateItemPipeline": 200,
    "myproject.pipelines.DeduplicatePipeline": 300,
    "myproject.pipelines.SaveToPostgresPipeline": 500,
}

选择器和字段规则也要留测试样本。页面结构一变，CSS/XPath 可能不会报错，只是悄悄返回空列表，这比直接失败更难发现。建议保存少量代表性 HTML，给关键解析函数写单元测试，再用小批量线上 URL 做集成检查。这样后面目标站改版时，你至少知道是选择器坏了、接口变了，还是反爬策略变了。

另一个经常被忽视的实践是把运行参数显式化。比如采集日期、入口 URL、批次号、是否全量，都通过 -a 参数或配置传入，不要硬编码在 spider 里。这样同一份代码既能跑日常增量，也能跑一次性补采，日志和数据里还能追溯来源。边界是参数越多越容易误传，关键参数最好在 from_crawler 或 __init__ 里校验，不合法就尽早失败。

追问

并发数和下载延迟怎么取舍？

并发高能提高吞吐，但也会放大目标站压力、错误率和封禁概率。下载延迟能让请求更温和，却会拉长任务时间，数据时效性要求高的业务可能接受不了。我的做法是先固定单域名并发，再用 AutoThrottle 看延迟变化，而不是一上来把 CONCURRENT_REQUESTS 调到很大。判断标准不是“跑得快”，而是 2xx 比例、平均响应时间和被限流次数是否稳定。

User-Agent 池和代理池是不是必备？

不是。公开文档、开放站点、内部站点通常不需要复杂代理池，反而应该用清晰的 User-Agent 和联系方式。代理池适合目标站有地域限制、频控严格或业务确实需要高吞吐的场景，但它会带来 IP 质量、成本、失败率和合规风险。常见踩坑是代理不可用时没有熔断，Scrapy 反复重试，最后把错误流量放大。先判断是否真的需要代理，再设计代理失败后的降级策略。

为什么建议用 scrapy shell 测选择器？

scrapy shell 能快速验证 CSS/XPath，不用每改一次就启动完整任务。它特别适合处理页面结构不稳定的站点，可以马上看出选择器是否拿到了空值、重复节点或脏文本。边界是 shell 只能验证单页，不能代表翻页、登录态、异步接口都没问题。上线前仍然要跑小批量任务，检查 item 完整率和异常日志。

日志应该记录到什么程度？

日志太少，线上问题只能猜；日志太多，磁盘和检索成本都会上来。建议 INFO 记录任务阶段、抓取数量、关键参数，WARNING 记录字段缺失、重试变多、响应异常，ERROR 记录真正影响数据完整性的失败。不要在日志里打印大量 HTML 或敏感 cookie，这类坑排查时很常见。生产环境还要让日志带上 spider 名、批次号和请求 URL，后续定位会快很多。

分布式爬虫什么时候再引入？

只有当单机 Scrapy 的瓶颈已经明确，比如队列太大、任务窗口太短、单机带宽或 CPU 不够，再考虑 scrapy-redis 或自研调度。分布式会带来去重一致性、任务恢复、节点监控和数据幂等问题，不是简单“多开几台机器”。如果业务每天只抓几万页，先把单机调度、pipeline 和监控做好更划算。过早分布式，往往会把一个小问题拆成三台机器上的大问题。

小结

Scrapy 最佳实践不是一组漂亮配置，而是一套工程习惯：尊重目标站、控制节奏、拆清职责、记录关键指标、先小流量验证。只要这些基础稳住，后面无论加代理、分布式还是监控，都不会把项目推向不可维护。