蜘蛛来抓一個頁面的时候，第一步並不是判断内容好不好，而是先要拿到响應。如果服務器迟迟不给答复，或者干脆返回 5xx，這一次抓取就落空了。偶尔一次問题不大，但如果某些模板長期慢、長期报错，蜘蛛會自然地把有限的抓取時間挪到更顺畅的地方去——這不是什么惩罚机制，只是效率選擇。
先確認問题出在哪一层
不要一上来就改代碼。先拿到两组資料：狀態碼分布和响應時間分布。前者說明有多少請求是失敗的，後者說明有多少請求是慢的，两個問题经常混在一起，但處理方式完全不同。
- 狀態碼：按 2xx、3xx、4xx、5xx 分组，看 5xx 集中在哪些路径
- 响應時間：按模板归類，找出長期偏慢的那几類頁面
- 時間分布：看變慢是全天如此，還是集中在某些时段
如果只盯着平均值，很容易被少數极端值带偏，所以更要看的是慢請求占比，而不是單次最慢有多慢。
响應時間一般從哪来
網絡與前置层
DNS 解析、CDN 回源、负载均衡轉發，這些环节出問题通常表現為整体偏慢，而不是某几個頁面慢。如果你發現几乎所有地址的响應時間一起上升，先看這一层，而不是急着查資料库。
應用與資料库
只有部分模板慢，多半在應用层：慢查询、循环里反复調接口、每次請求都重新生成同样的内容。列表頁、搜尋结果頁、多條件篩選頁是常见的重灾区，這類頁面往往參數多、组合多，最容易把响應時間拖長。
外部依赖
第三方接口超时會把整頁卡住。给外部調用設定獨立的超时時間和降級方案，避免一個並不重要的模块拖垮整個頁面的响應。
5xx 與超时的處理原則
- 能修的尽快修，不要把 5xx 当作临时挡板。频繁报错會让蜘蛛認為這個站点不稳定，降低回来的意愿。
- 确實需要临时下线时，用 503 並配合 Retry-After，明确告知什么时候可以再来，比返回 404 或者一個 200 的空頁面都更清楚。
- 避免半截頁面。返回的 HTML 要完整可解析，不要出現主内容缺失、只剩框架的情况。
缓存值得先做，但不是萬能
静態化、頁面缓存、對象缓存能挡掉大部分重复計算，是最省力的改善手段。不過要注意缓存穿透：缓存刚好失效的瞬間，大量請求同时打到源站，反而更容易超时。可以用過期時間错開、同一時間只允许一個請求回源等办法缓解。
日常怎么盯着
- 把關键入口頁加入监控，包括首頁、主要栏目頁和核心詳情模板，按小时看响應時間
- 在抓取日誌里統計超时與 5xx 的數量，按周對比變化趋势
- 巡检时手動打開几個頁面，感受真實加载速度，不要只看监控曲线
提醒一句：不要因為蜘蛛抓得勤就想给它限速。限流規則誤伤正常蜘蛛，造成的损失往往比响應偏慢更大。
處理的顺序
先把最慢的一两個模板修好，观察一段時間；再處理偶發的超时；最後再谈整体優化。不要同时改一堆東西，否則出了問题很难分清是哪一步起了作用。响應這件事没有一次性解决的方案，它更像是一項要長期保持的日常维護工作。