排查抓取問题时，很多人先看 robots、Sitemap 和内鏈，却忽略一個更基础的前提：蜘蛛得先成功拿到响應。如果服務器在一個頁面上拖太久，蜘蛛通常不會一直等下去，這一次抓取就白費了。
蜘蛛的等待是有上限的
一次抓取本质上就是一次 HTTP 請求，同样受连接超时和讀取超时约束。连接阶段失敗，說明服務器根本没接受請求；讀取阶段超时，說明连上了但内容迟迟没吐出来。两者在日誌里的表現完全不同，排查方向也不一样。
各家爬虫的阈值不公開、也會調整，所以没必要去找一個精确秒數。更實用的判断是：响應越慢，單次抓取被放弃的概率越高，而慢頁面往往恰好是内容最多、最需要被抓的那些頁面。
哪些环节會把响應拖長
- 資料库慢查询：列表頁缺少合适索引，翻頁越深越慢，分頁 URL 首当其冲。
- 同步調用外部接口：评论、推荐位、統計脚本等第三方請求一旦挂住，整個頁面陪着一起等。
- 缓存击穿：缓存刚過期的那一瞬間，請求全部打到源站，如果正好赶上蜘蛛来訪，体驗最差。
- 回源鏈路：CDN 节点未命中时回源慢，邊缘等待同样計入响應時間。
- 並發排队：服務器连接池被用戶占满，蜘蛛請求排到队列尾部。
用日誌和监控定位問题頁面
- 先按蜘蛛 UA 筛出訪問记錄，按响應時間排序，看是全局偏慢還是集中在少數 URL 模板上。
- 把首字节時間和完整加载時間分開看，抓取更在意前面那一段。
- 對照同时段的用戶請求，判断是站点整体抖動，還是只對蜘蛛做了限速。
- 检查狀態碼分布，超时经常表現為 502、504，或者干脆没有留下完整记錄。
让重要頁面稳定返回
缓存放在最前面
詳情頁、栏目頁這類讀多寫少的内容，尽量在應用层生成静態或半静態结果，让蜘蛛和用戶走同一條快路径，而不是每次請求都穿透到資料库。
给外部依赖加超时和降級
- 所有外部請求設定明确的超时時間，超时後返回空内容，而不是繼續等。
- 非核心模块失敗时不要影响主内容輸出，推荐位可以空缺。
- 把耗时任務改成异步，頁面只渲染最终结果。
別把蜘蛛和用戶简單對立
有的站点為了省资源，單獨给蜘蛛加了很嚴的限速，结果抓取量下降。更稳的做法是识別真實爬虫身份後给合理配額，同时對異常高频請求做限制，而不是一刀切。
分段輸出不總是好事
流式輸出能让浏览器更早渲染，但如果首段内容迟迟不開始發送，蜘蛛拿到的仍然是一段長時間的等待。關键指标是首字节什么时候返回，而不只是總时長。
把蜘蛛当成一個没耐心的普通訪客：它會来，但不會等你太久。頁面响應稳定，比任何提交技巧都更基础。
一份简單的巡检清單
- 随机抽 10 個重要 URL，用不带缓存的請求测首字节時間。
- 检查最近一周蜘蛛訪問的超时比例，超出可接受范围就回头查慢查询。
- 確認缓存命中率，尤其是半夜和内容更新之後的時間段。
- 核對服務器扩容、维護窗口是否與抓取高峰撞车。