缓存为什么会变成蜘蛛池的变量
蜘蛛池的入口页通常数量大、更新频繁，很多站点为了扛住集中抓取，会在前面加一层 CDN 或反向代理缓存。这时候蜘蛛拿到的内容，不一定是你源站此刻正在输出的那一份。对做 URL 发现和站点运营的人来说，麻烦在于：你改了入口页的链接结构，蜘蛛那边可能还在读旧版本，于是抓取路径看起来毫无变化。
先把概念理清楚：缓存不是“好”或“坏”，它只是一种“把某一份响应多停留一会儿”的机制。关键是你要知道哪一份被停留了、停留多久、对谁停留。
入口页可能出现的三种缓存状态
- 完全回源：每次请求都打到源站，蜘蛛拿到的一定是最新版，但服务器压力最大。
- 边缘命中：CDN 节点直接返回缓存副本，速度快，但你更新后的一段时间里，蜘蛛读到的仍是旧内容。
- 混合状态：不同节点、不同地区、不同 UA 命中情况不一样，同一批入口页在蜘蛛眼里版本混乱。
第三种最容易出问题。你在一台机器上测得好好的，蜘蛛从另一个出口访问却拿到了旧缓存，于是你会得到互相矛盾的抓取日志。
几个常见的误区
改了源站，蜘蛛就该立刻看到
缓存有效期没到，或者 CDN 没被通知刷新，蜘蛛就看不到。尤其是给静态入口页设了较长 TTL 的时候，这种延迟会非常直观。
把爬虫都当成普通访客
有些配置会给移动端、PC 端返回不同模板，或者根据 UA 走不同逻辑。如果缓存键没有把这些维度拆开，就会出现“A 蜘蛛拿到 B 版本”的情况。这类问题不会报错，只会让入口页里出现的链接莫名其妙。
只刷首页，不刷入口页
入口页数量多、路径深，往往不在常规刷新范围内。批量更新后如果只刷了几个主入口，剩下的会长期停在旧版本上。
配置上的几个务实做法
- 把入口页的缓存时间设短一些，或者用较短 TTL 配合回源校验，让新鲜度和抗压能力之间有个折中。
- 缓存键要把影响输出的维度算进去：域名、路径、查询参数、设备类型，必要时再加 UA 分类。否则命中就是错位命中。
- 批量改版后主动做一次缓存刷新，把入口页目录一起提交，而不是逐个手点。
- 如果入口页内容本身很少变化，长缓存可以接受；但要确保新增链接尽快出现在被缓存的那份页面里，否则 URL 发现会滞后。
- 给抓取量大的路径单独设策略，不要和全站默认策略混在一起。
判断缓存有没有拖后腿，最简单的办法是：在源站加一个临时标记（比如只在回源时才出现的注释或响应头），然后看蜘蛛的请求结果里有没有它。
怎么观察和验证
看日志的时候，别只看状态码。把相同 URL 的响应长度、Last-Modified、内容摘要拉出来对比，能比较快地判断是不是有多份版本在同时被人读。如果发现某个入口页被读到的内容和你预期不符，先查缓存，再查是否被中间层改写，最后才怀疑模板本身。
需要提醒的是，把缓存配好只是让蜘蛛“看到该看到的东西”，它并不决定蜘蛛是否来、是否继续往下走。入口页能不能被稳定读到，是后续所有观察的前提，但它本身不等于效果。