Scrapy默认深度优先（DFS）源于LifoMemoryQueue栈结构，非DEPTH_PRIORITY控制；需广度优先（BFS）时应改用FifoMemoryQueue并启用深度中间件，配合meta['depth']守卫和低并发保障层级顺序。
Scrapy 默认就是深度优先（DFS），不是“问题”，而是行为本身——如果你想要广度优先（BFS）或可控的层级爬取顺序，才需要主动干预。
Scrapy 默认是深度优先，但不是靠 DEPTH_PRIORITY 控制的
很多教程误传“默认 DEPTH_PRIORITY=0 就是深度优先”，其实这是错觉。Scrapy 默认使用 LifoMemoryQueue（后进先出栈），天然导致新发现的请求被优先处理，形成事实上的深度优先行为。它和 DEPTH_PRIORITY 无关——这个参数只在启用深度感知调度时才起作用，且仅影响同深度请求间的排序权重。
-
DEPTH_PRIORITY为正数（如1）时：越浅的请求越靠前 → 倾向广度优先 -
DEPTH_PRIORITY为负数（如-1）时：越深的请求越靠前 → 强化深度优先 - 但前提是必须启用深度中间件：
DEPTH_LIMIT和DEPTH_STATS_VERBOSE等配置要配合，否则DEPTH_PRIORITY不生效
真正想控制多级分类页面的爬取顺序，得换队列类型
多级分类页（比如「首页 → 分类A → 子类A1 → 商品列表」）常因深度优先导致：刚进分类A就一路钻到最底层商品页，而分类B、C还没开始抓。要让 Scrapy 先扫完所有一级分类页，再统一进二级，就得强制用 FIFO 队列。
- 在
settings.py中设置：DEPTH_PRIORITY = 1 SCHEDULER_DISK_QUEUE = 'scrapy.squeues.PickleFifoDiskQueue' SCHEDULER_MEMORY_QUEUE = 'scrapy.squeues.FifoMemoryQueue'
- 注意：必须同时改内存队列和磁盘队列，否则调度器行为不一致
- 如果启用了
DUPEFILTER_CLASS或自定义去重逻辑，FIFO 不影响去重，但要注意meta中携带的深度信息是否被正确传递
用 meta['depth'] + 条件 yield 控制实际爬取层级
光靠队列类型不够稳定，尤其当页面内链接混杂（既有同级分类，又有跳转详情页）。更可靠的做法是在解析回调里显式判断当前深度，并决定是否继续 follow：
立即学习“Python免费学习笔记（深入）”；
- 在
start_requests或第一层parse中，给请求带上meta={'depth': 0} - 后续每层
response.follow或scrapy.Request时递增：meta={'depth': response.meta['depth'] + 1} - 在目标解析方法中加守卫：
if response.meta.get('depth', 0) >= 2: return # 只允许爬两级：首页→分类→子分类，不进商品页 - 这样比依赖全局调度更精准，也避免因并发数高导致的深度“穿刺”
容易忽略的坑：并发与深度感知冲突
Scrapy 的深度统计是基于请求入队顺序的，但高并发（CONCURRENT_REQUESTS > 1）会让多个深度不同的请求并行发出，导致 depth 字段在响应中不可靠——比如一个 depth=1 的请求可能比 depth=0 的响应还慢回来。
- 若需严格按层执行，应设
CONCURRENT_REQUESTS = 1，或用DOWNLOAD_DELAY+AUTOTHROTTLE_ENABLED = True缓冲 - 不要在 pipeline 或 item 处理阶段依赖
meta['depth']做逻辑分支，因为此时响应已返回，深度信息可能已失真 - 真正需要层级隔离的场景（如先存分类树，再抓商品），建议拆成两个独立 spider，用信号或文件标记进度，比硬调调度器更稳
深度优先本身不是 bug，它是 Scrapy 调度器的默认行为；所谓“问题”，其实是没意识到队列类型、深度中间件、并发策略三者如何协同。改配置不如先理清你到底要“先横向扫完再往下”，还是“每个分支尽快走到底”——前者靠 FIFO 队列，后者靠默认栈+深度守卫。
