蜘蛛抓取不是凭空發生的。它每一次請求都會占用服務器的连接數、CPU、带宽和資料库查询。平时流量小的时候看不出来，一旦站点集中更新、Sitemap 重新提交、新頁面被大量外部引用，抓取請求和真實用戶訪問叠在一起，服務器余量不足的問题就會暴露出来。
抓取高峰通常出現在什么时候
抓取量並不是全天平均分布的，它往往跟着站点的動作走。比較常见的集中时段有這几類：
- 站点批量發布内容或整站改版之後，新舊 URL 同时被抓；
- Sitemap 更新並重新提交後，里面新增的一批地址被排队讀取；
- 某篇内容被外部頁面引用，新的入口把蜘蛛引向一批歷史 URL；
- 列表頁、分頁结构或标簽頁改版，内鏈把蜘蛛带進原本冷门的栏目；
- 日誌里某個栏目突然被反复抓取，說明有新的連結路径指向了它。
這些動作本身没有好坏之分，問题在于它們常常和业務高峰撞在一起，比如活動上线、促销開抢、内容集中推送的时段。
蜘蛛的請求會吃掉哪些资源
- 带宽出口：大頁面、图片、附件被反复讀取时，出口流量會明顯上升。
- 應用层 CPU：動態頁面每次都要经過模板渲染、參數計算、權限判断。
- 資料库连接：未命中缓存的查询會反复落到資料库上，连接池容易被占满。
- 缓存穿透：抓取請求的 URL 组合和真實用戶不一致时，缓存命中率反而更低。
- 日誌寫入：抓取量上来之後，訪問日誌本身的寫入也會成為一筆開销。
静態文件為主的站点，压力主要在带宽；以動態查询、搜尋頁、篩選頁為主的站点，压力更多落在應用和資料库上。判断时先看自己的頁面類型，而不是只看請求數。
响應變慢之後，蜘蛛侧會發生什么
服務器响應時間變長，蜘蛛並不會立刻停止訪問，但它會做出一系列調整：單次請求超时被记為失敗，部分连接被放弃，重试次數增加，整体抓取速率下降。如果同时出現較多 5xx 或连接中断，抓取量通常會在接下来一段時間里收缩，恢复得比下降慢。
慢响應不會立刻带来戏剧性的结果，但它會让新 URL 被發現得更晚、舊 URL 更新得更慢，抓取覆盖的推進速度整体被拖住。
给抓取留余量的几個做法
- 先量化再優化：看响應時間的分位值（P95、P99），不要只看平均值，平均值會把慢請求盖住。
- 给動態路径加缓存：列表頁、詳情頁做頁面級缓存或片段缓存，能直接减少資料库查询。
- 把静態與動態分開服務：图片、CSS、JS 走 CDN 或獨立域名，避免和應用抢同一批连接。
- 控制單頁体积：减少首屏之外的同步請求，蜘蛛和用戶都會受益。
- 關注 5xx 和超时：這两類错誤比 404 更值得優先處理，它們會直接影响抓取节奏。
- 错峰安排批量動作：發布、改版、Sitemap 提交尽量避開业務高峰。
需要提醒的是，不要為了节省资源去屏蔽重要目錄或對蜘蛛做過于激進的限制，那會把资源問题換成發現和收錄問题。
調整之後怎么驗證
驗證周期建议按周看，而不是按天。重点观察几項：日誌里蜘蛛請求的响應時間分布是否下降，5xx 與超时的比例是否收敛，單日抓取請求量是否回升，以及之前長期没有動静的 URL 是否開始出現抓取记錄。如果抓取量没變但 5xx 明顯减少，也是有效的改善，說明服務器重新有了余量。
抓取余量的本质是把服務器资源当作一個有限的池子来管理。站点規模不大时，重点是別让個別慢頁面拖住整体响應；站点規模變大後，重点是让抓取速率和站点能承受的节奏大致匹配。這两件事都不靠一次性設定完成，而是靠日誌持續校准。