scrapy调试需深入请求流转链：用scrapy shell验证中间件真实生效；在parse和downloader middleware中设pdb断点；通过debug日志观察“scheduler已接收”“downloading”“crawled”三阶段；用main.py在pycharm中全程跟踪请求流向。
想在Scrapy爬虫中精准定位请求发不出去、响应拿不到、中间件没生效等问题，必须深入请求流转链条调试，而不是只看parse函数里的断点停在哪。
用scrapy shell实时验证请求与响应
打开终端，进入Scrapy项目根目录，执行：
scrapy shell "https://example.com"
这会启动一个交互式环境，自动完成引擎初始化、下载器加载、中间件注册等全过程，【所有Downloader Middleware和Spider Middleware都会真实启用】。
输入fetch(req)可重放任意Request对象，输入response.body或response.status立刻查看原始响应内容。
注意：shell中定义的临时中间件不会自动加载，必须先在settings.py中启用再启动shell，否则process_request/process_response根本不会触发。
在parse中插入断点并控制请求流速
第一步：在parse方法开头加一行
import pdb; pdb.set_trace()
第二步：确保只发起单个请求，注释掉所有yield scrapy.Request(...)，仅保留一个测试用的request，例如：
yield scrapy.Request(url="https://httpbin.org/get", callback=self.parse_test)
第三步：运行爬虫命令scrapy crawl your_spider_name，程序会在pdb处暂停。此时可检查request对象的url、headers、meta是否符合预期；输入c继续后，观察是否真正发出请求——若未发出，说明被Downloader Middleware拦截或丢弃。
第四步：在parse_test回调中再次pdb.set_trace()，确认response是否到达、status是否为200、body是否含目标数据。这一步能排除DNS解析失败、SSL证书错误、超时等网络层问题。
通过日志逐层定位中断点
方法一：启用Scrapy内置DEBUG级别日志
在命令行运行时添加--loglevel=DEBUG参数：
scrapy crawl demo --loglevel=DEBUG
方法二：在settings.py中强制开启关键组件日志
LOG_LEVEL = 'DEBUG'
LOG_FORMAT = '%(asctime)s [%(name)s] %(levelname)s: %(message)s'
LOG_DATEFORMAT = '%Y-%m-%d %H:%M:%S'
重点观察以下三类日志行：
• “Scheduler has received request” → 请求已入队
• “Downloading
• “Crawled (200)
如果看到第一行但看不到第二行，说明调度器卡住或并发数设为0；如果看到第二行但无第三行，大概率是Downloader Middleware中的process_request修改了request导致异常，或process_response未正确返回response。
在Downloader Middleware中加断点调试代理与UA逻辑
打开你的中间件文件（如middlewares.py），在process_request方法第一行插入：
import pdb; pdb.set_trace()
确保该中间件已在settings.py的DOWNLOADER_MIDDLEWARES中启用且优先级非零，例如：
DOWNLOADER_MIDDLEWARES = {
'myproject.middlewares.MyProxyMiddleware': 543,
}
运行爬虫后，只要request经过此中间件就会暂停。此时可检查request.meta.get('proxy')是否已设置、headers中User-Agent是否被覆盖、是否误将request赋值为None（这会导致请求直接丢弃）。
【切勿在process_request中return None，这会使请求彻底消失且无任何报错】
用main.py入口启动PyCharm调试会话
在项目根目录新建main.py，内容为：
from scrapy.cmdline import execute
execute(['scrapy', 'crawl', 'demo'])
在PyCharm中右键main.py → Debug 'main'，即可完整复现scrapy crawl命令的启动路径。
此时可在cmdline.py第127行（调用_crawl方法处）、engine.py的next_request()、downloader.py的_fetch_request()等核心位置下断点，真正看清请求如何从Spider流向Downloader，再如何从Downloader回到Spider。
这一步不需要修改任何Scrapy源码，PyCharm会自动关联已安装的scrapy包源码。
