蜘蛛来抓一個頁面，不等于它把頁面完整拿走了。日誌里狀態碼是 200、看起来一切正常，但如果响應時間太長、响應体太大或者连接中途断開，蜘蛛很可能只拿到一部分就放弃，後面的内容不會進入處理流程。下面從時間、体积和连接三個角度，说清楚蜘蛛在什么情况下會中途收手，以及站点侧能做什么。
一次抓取里三個容易被忽略的预算
時間预算：首字节和整体耗时
蜘蛛等待的是两段時間——服務器多久返回第一個字节（TTFB），以及整個响應多久結束。TTFB 長期偏高的目錄，蜘蛛通常會降低回訪意愿；整体耗时超過它的讀取上限时，抓取會被中断，日誌里可能只留下一個未完成的請求。
体积预算：响應体有讀取上限
搜尋引擎不會無限制地讀取一個响應。超過一定大小的 HTML，後面的部分往往不會被繼續處理。如果正文被大量模板代碼、内联脚本、base64 图片挤到很靠後的位置，蜘蛛「看到」的内容可能並不是你希望它看到的那部分。
连接预算：同一连接上的连續請求
蜘蛛习惯在一個连接上连續請求多個 URL。如果服務器在连接复用上不稳定，或者中途主動断開，後續 URL 就要重新建连，抓取节奏會被整体拖慢。
蜘蛛中途放弃时，日誌里長什么样
- request_time 明顯高于平时，但狀態碼仍是 200
- body_bytes_sent 明顯小于同類頁面的平均水平，說明响應没發完
- 499、连接重置、空响應，通常是客戶端先断開
- 同一时段請求集中在少數几個重頁面，其他 URL 很少被訪問
這些信号單獨看都不够确定，放在一起看就比較清晰：如果一個頁面的平均响應体积長期偏小、耗时又偏高，它大概率没被完整抓走。
容易触發中断的几類頁面
- 依赖實时接口渲染、又没有缓存的列表頁與詳情頁
- 單頁 HTML 体积很大，正文却排在中後段
- 图片以内联编碼方式寫進 HTML，把頁面撑得很大
- 首屏依赖大量外部资源的頁面，服務端等待時間被拉長
- 資料库慢查询直接暴露给前端的頁面
站点侧可以做的調整
- 给動態頁面加一层缓存，先把 TTFB 压下来，再谈抓取频次。
- 把正文尽量前置，模板導航、脚本放在正文之後或外鏈引入。
- 大頁面拆分成分頁或分章节，让每一頁都在体积上限之内。
- 懒加载的内容要有可被普通請求拿到的連結或資料，不能只靠滚動触發。
- 检查连接复用配置，避免服務端在 keep-alive 下频繁主動断開。
- 對蜘蛛單獨观察限速與並發，不要用统一的防護規則把它一起限制掉。
怎么確認蜘蛛是否抓全了
最直接的办法是把日誌里的請求耗时和响應字节數與自己的抓取做對比：用相同的 User-Agent 請求同一個 URL，比較返回体积、狀態碼和耗时。如果线上响應明顯更慢或更小，說明問题出在服務端而不是蜘蛛。也可以用命令行工具记錄完整的响應头和响應体大小，作為排查的基线。
蜘蛛的放弃往往是静默的：狀態碼正常，内容却不完整。把响應時間、响應体积和连接稳定性当成抓取质量的三個指标来观察，比單纯盯回訪次數更容易找到問题。