抓取高峰时有人发现网站变慢，第一反应往往是“蜘蛛把服务器压垮了”。这个判断有时对，有时错。抓取请求和真实用户请求走的是同一条链路，但两者特征差别很大，分清楚谁在占资源，才知道该改哪里。
抓取请求和用户请求有什么不同
- 抓取请求通常集中在少数 URL 模板上，比如列表页、详情页、标签页，短时间内反复访问同一批地址。
- 用户请求分散且带会话，会触发登录、推荐、购物车这类偏重的业务逻辑。
- 抓取请求大多不带 Cookie，不加载图片和样式文件，但会完整读取 HTML 内容。
当监控显示 CPU 占用或数据库连接数上涨时，先看是“某个模板的请求量涨了”还是“所有页面的请求量都涨了”。前者更像抓取，后者更像用户流量变化或异常攻击。
哪些页面最容易被抓取拖慢
- 没有缓存的动态页：每次抓取都要查库、拼模板、调接口。
- 搜索结果页和筛选页：参数组合多，一次抓取可能引出大量组合 URL。
- 站内搜索接口：如果对蜘蛛开放，一次检索就是一次偏重的查询。
- 未做静态化处理的图片或文件目录：单个请求很小，但并发容易堆高。
怎么确认影响确实来自抓取
- 在访问日志里按 User-Agent 过滤，把蜘蛛请求单独算一份 QPS，再和总 QPS 对照。
- 看时间分布：抓取在流量低谷也往往保持稳定请求量，而用户流量通常随作息起伏。
- 看响应时间：如果蜘蛛拿到的响应时间明显比用户短，说明它们抓的多是缓存命中的页面，压力未必来自这里。
- 把慢查询日志和抓取时间对照，看是不是同一批 URL 模板在反复触发重查询。
可以做的调整
- 给动态页设置合理的缓存时间，让同一 URL 的重复抓取命中缓存而不是打到数据库。
- 把重复参数、无意义筛选页用规范标签或 robots 规则收敛，减少蜘蛛被引到低价值组合上。注意 robots 的语义是“不建议抓取”，本身不是限速工具。
- 用 CDN 或反向代理分担静态资源，源站只处理必须实时生成的请求。
- 在服务器层面做并发限制，比依赖 crawl-delay 更可控，主流搜索蜘蛛并不保证遵守它。
- 把访问密集的模板改成预生成或增量更新，减少每次请求的实时计算。
不建议做的事
为了省资源直接屏蔽搜索蜘蛛，短期看带宽降下来了，长期是入口变少。真正需要处理的是“哪些 URL 不值得被反复抓”，而不是“要不要让蜘蛛来”。常见做法是先收紧参数页和站内搜索，观察一段时间再决定是否继续调整。
抓取压力往往不是总量问题，而是结构问题：少数本不该被抓的 URL 模板，承担了大部分请求。
观察节奏与验证
调整之后不要马上判断效果。抓取行为存在滞后，尤其是在刚改动 robots 或链接结构时，蜘蛛可能还在按旧路径访问。建议连续观察一到两周，对比抓取请求数、缓存命中率和用户端响应时间三项指标，再决定下一步动作。