蜘蛛抓取對站点来说更像一次持續的外部压力測試：它不挑時間、不看业務节奏，只按自己的队列發請求。很多站点在日常流量下一切正常，一旦蜘蛛把抓取並發提上来，响應時間和错誤率就同时抬头。這里讨论的不是怎么让蜘蛛多抓，而是抓取高峰来临时，服務器端怎么稳住，別把正常的發現與抓取节奏打断。

抓取高峰暴露的通常不是带宽

带宽往往最先被怀疑，但真正先出問题的通常是下面這些环节：

• 缺少索引或缓存的長尾頁查询，單頁触發多次資料库訪問；
• 動態渲染鏈路（模板加接口组合）在並發下延迟叠加；
• 單机连接數與進程數上限，請求開始排队；
• 日誌寫入與磁盘 IO 在抓取密集时拖慢响應。

這些环节平时被低频的用戶請求掩盖，蜘蛛一旦對某個栏目、某段分頁连續抓取，就會同时把它們压出来。

先把並發量清楚

先從訪問日誌統計單位時間内的抓取請求數、獨立来源數量、狀態碼分布和响應時間分位（p95、p99）。不要只看總量，要看峰值能持續多久。

• 区分真實蜘蛛與伪装 UA，用反向解析和 IP 段核對来源；
• 观察平均响應時間上升时，抓取並發是否同步上升；
• 找出贡献請求最多的目錄與 URL 模式，判断是正常覆盖還是無效路径消耗。

量清楚之後，限速和扩容才有依據，否則很容易把一次正常抓取当成攻击處理。

在入口限速，而不是在應用里硬扛

比較稳妥的做法是在反向代理或網關层對抓取流量做並發與速率限制，让請求排队或快速失敗，而不是把压力透传到資料库。

• 按核對過的蜘蛛来源設定單獨通道，和普通用戶流量分開統計；
• 設定單来源並發上限與每秒請求上限，超出的先排队再拒绝；
• 静態资源、图片、接口與頁面分開策略，別让静態文件挤占頁面抓取；
• 阈值留出余量，避免抓取正常波動时被誤伤。

直接封死某個来源往往得不偿失，一旦是真實蜘蛛，恢复抓取的時間可能比预想的長。

降低單次抓取的成本

• 给列表頁、詳情頁加缓存，缓存命中率是應對抓取峰值最便宜的手段；
• 首屏所需資料尽量一次查询取完，避免一個頁面触發几十次資料库訪問；
• 抓取触發的寫操作（計數、推荐、足迹）要异步化或降級，不让讀請求带動寫；
• 渲染較重的頁面可以做静態化或服務端预渲染，减少每次拼装成本。

宁可少抓，也別返回 5xx

服務器過载时返回 5xx 或连接超时，對抓取节奏的伤害比限速更直接：蜘蛛會退避、降低频率，恢复需要時間。

如果确實需要临时限流，用明确的 429 或 503 並带上 Retry-After，比让請求挂着超时要好。维護窗口内的 503 是合理信号，但不要让它常態化。

把“限速”和“故障”分開表達，蜘蛛才能判断是该等一會儿還是该登出。

监控與容量安排

• 盯住响應時間分位、错誤率、活跃连接數和缓存命中率；
• 把抓取請求量和發現、抓取覆盖趋势放在一起看，判断是不是容量問题；
• 發布、改版或大批量新增 URL 前，提前预估抓取增量。

蜘蛛抓取不是一次性事件，而是長期回訪。站点要做的不是某天扛住峰值，而是让每次回訪都在可预期的资源范围内完成。稳定、可预测的响應，比偶尔一次飞速响應更有價值。