抓取高峰时有人發現網站變慢，第一反應往往是“蜘蛛把服務器压垮了”。這個判断有时對，有时错。抓取請求和真實用戶請求走的是同一條鏈路，但两者特征差別很大，分清楚谁在占资源，才知道该改哪里。
抓取請求和用戶請求有什么不同
- 抓取請求通常集中在少數 URL 模板上，比如列表頁、詳情頁、标簽頁，短時間内反复訪問同一批地址。
- 用戶請求分散且带會话，會触發登入、推荐、购物车這類偏重的业務逻辑。
- 抓取請求大多不带 Cookie，不加载图片和样式文件，但會完整讀取 HTML 内容。
当监控顯示 CPU 占用或資料库连接數上涨时，先看是“某個模板的請求量涨了”還是“所有頁面的請求量都涨了”。前者更像抓取，後者更像用戶流量變化或異常攻击。
哪些頁面最容易被抓取拖慢
- 没有缓存的動態頁：每次抓取都要查库、拼模板、調接口。
- 搜尋结果頁和篩選頁：參數组合多，一次抓取可能引出大量组合 URL。
- 站内搜尋接口：如果對蜘蛛開放，一次检索就是一次偏重的查询。
- 未做静態化處理的图片或文件目錄：單個請求很小，但並發容易堆高。
怎么確認影响确實来自抓取
- 在訪問日誌里按 User-Agent 過滤，把蜘蛛請求單獨算一份 QPS，再和總 QPS 對照。
- 看時間分布：抓取在流量低谷也往往保持稳定請求量，而用戶流量通常随作息起伏。
- 看响應時間：如果蜘蛛拿到的响應時間明顯比用戶短，說明它們抓的多是缓存命中的頁面，压力未必来自這里。
- 把慢查询日誌和抓取時間對照，看是不是同一批 URL 模板在反复触發重查询。
可以做的調整
- 给動態頁設定合理的缓存時間，让同一 URL 的重复抓取命中缓存而不是打到資料库。
- 把重复參數、無意义篩選頁用規范标簽或 robots 規則收敛，减少蜘蛛被引到低價值组合上。注意 robots 的语义是“不建议抓取”，本身不是限速工具。
- 用 CDN 或反向代理分担静態资源，源站只處理必须實时生成的請求。
- 在服務器层面做並發限制，比依赖 crawl-delay 更可控，主流搜尋蜘蛛並不保證遵守它。
- 把訪問密集的模板改成预生成或增量更新，减少每次請求的實时計算。
不建议做的事
為了省资源直接屏蔽搜尋蜘蛛，短期看带宽降下来了，長期是入口變少。真正需要處理的是“哪些 URL 不值得被反复抓”，而不是“要不要让蜘蛛来”。常见做法是先收紧參數頁和站内搜尋，观察一段時間再决定是否繼續調整。
抓取压力往往不是總量問题，而是结构問题：少數本不该被抓的 URL 模板，承担了大部分請求。
观察节奏與驗證
調整之後不要马上判断效果。抓取行為存在滞後，尤其是在刚改動 robots 或連結结构时，蜘蛛可能還在按舊路径訪問。建议连續观察一到两周，對比抓取請求數、缓存命中率和用戶端响應時間三項指标，再决定下一步動作。