concurrent_requests 控制 downloader queue 中同时发出的请求数，非响应处理数或qps；其效果受多 spider、中间件、auto_throttle 等影响，且与 download_delay 正交；需注意 per-domain 限频不防 ip 封禁，debug 时 concurrent_requests=0 通常是延迟等待所致。
CONCURRENT_REQUESTS 设置后没效果？先看它管的是哪层并发
Scrapy 的 CONCURRENT_REQUESTS 控制的是「同时发出的请求数」，不是「同时处理的响应数」，更不等于「每秒请求数」。它只作用于 downloader queue 中正在被 downloader 处理的请求——也就是说，爬虫生成了 100 个 Request，但真正发出去的最多只有 CONCURRENT_REQUESTS 个，其余排队等空位。
常见错误现象：CONCURRENT_REQUESTS = 1 却看到日志里多个 Downloading 同时出现。这通常是因为：你开了多个 spider（比如用 scrapy crawl spider1 & scrapy crawl spider2），或者用了 CrawlSpider 规则触发了多路并行解析，又或者中间件/扩展偷偷发了额外请求（如自动重试、AJAX 渲染插件）。
-
CONCURRENT_REQUESTS是全局设置，对所有 spider 生效；若需 per-spider 控制，改用custom_settings字典里的'CONCURRENT_REQUESTS': 2 - 它和
DOWNLOAD_DELAY是正交关系：延迟影响「单个 downloader slot 发出下个请求前要等多久」，而并发数影响「多少个 slot 能同时干活」 - 如果启用了
AUTO_THROTTLE_ENABLED = True，CONCURRENT_REQUESTS会被动态压制——此时设再大也没用
DOWNLOAD_DELAY 和 RANDOMIZE_DOWNLOAD_DELAY 怎么配才不被封
单纯设 DOWNLOAD_DELAY = 1 每次都卡死 1 秒，反而容易暴露爬虫特征。真实站点喜欢用固定间隔做反爬识别，所以 Scrapy 默认开启 RANDOMIZE_DOWNLOAD_DELAY = True（除非你显式关掉），让实际延迟在 0.5 * DOWNLOAD_DELAY 到 1.5 * DOWNLOAD_DELAY 之间随机浮动。
使用场景：爬新闻站或电商详情页这类对频率敏感的目标时，建议组合使用：
-
DOWNLOAD_DELAY = 1.5—— 基准间隔拉长，避开多数默认限速阈值（如 Nginx 的 limit_req） - 保持
RANDOMIZE_DOWNLOAD_DELAY = True（默认值，不用写） - 加
AUTOTHROTTLE_START_DELAY = 1和AUTOTHROTTLE_MAX_DELAY = 3，让 Scrapy 自动根据响应时间微调节奏
注意：DOWNLOAD_DELAY 对 start_urls 里的初始请求也生效，但对 errback 或 callback 中手动 yield Request(...) 出来的请求同样有效——这点常被忽略，导致误以为“新请求没走延迟”。
为什么开了 CONCURRENT_REQUESTS_PER_DOMAIN 还是被封
CONCURRENT_REQUESTS_PER_DOMAIN 是按域名隔离并发的开关，但它只限制「同一 netloc（如 example.com）下的并发请求数」，不防 IP 封禁。如果你用的是代理池或公司出口 IP，多个域名请求全打到同一个 IP 上，目标站看的是源 IP 总频次，这时候 CONCURRENT_REQUESTS_PER_DOMAIN 就形同虚设。
参数差异：
-
CONCURRENT_REQUESTS_PER_DOMAIN = 2：对 a.example.com 和 b.example.com 分别限 2，并非总共 2 -
CONCURRENT_REQUESTS_PER_IP = True才真正按 IP 统计（需配合CONCURRENT_REQUESTS_PER_DOMAIN = 0或更大值，否则后者优先级更高） - 如果用了
scrapy-rotating-proxies类插件，记得关掉CONCURRENT_REQUESTS_PER_IP，否则可能因代理 IP 解析不稳定导致并发归零
性能影响：开 CONCURRENT_REQUESTS_PER_IP 会增加 downloader 内部路由判断开销，小规模爬取几乎无感，但万级 URL 下建议压测对比。
DEBUG：日志里看到 concurrent_requests=0 是怎么回事
这是 Scrapy 在等待 DOWNLOAD_DELAY 或 AUTOTHROTTLE 放行时的真实状态，不代表卡死。典型错误现象：设置 CONCURRENT_REQUESTS = 8，但日志一直显示 concurrent requests: 0，几秒后突然跳到 8——说明所有 slot 都在等延迟到期。
排查步骤：
- 检查是否误设了极大
DOWNLOAD_DELAY（比如 60），且RANDOMIZE_DOWNLOAD_DELAY = False - 确认没在
parse中用time.sleep()或同步 HTTP 请求阻塞了 Twisted reactor - 看
scrapy version -v输出，老版本（AUTOTHROTTLE 的初始化有 bug，可能导致初始 delay 被设成 inf - 临时加
LOG_LEVEL = 'DEBUG'，搜日志里schedule delay相关行，定位具体在哪卡住
最容易被忽略的一点：某些中间件（尤其是自定义的 process_request）如果抛了未捕获异常，会导致该请求直接丢弃、slot 不释放，表现就是并发数卡在某个值不上不下——务必确保所有中间件都有 try/except 包裹。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
