CDN 帮站点分担流量，也带来一个副作用：内容更新之后，边缘节点上还留着旧版本。用户看到的是旧页面，蜘蛛抓到的也可能是旧页面。反过来说，如果缓存配置得太松，回源压力又会明显上升。缓存这件事，值得按固定节奏自查一遍。
先确认问题是否真的存在
判断缓存有没有捣乱，最直接的办法是对比。用 curl -I 请求同一个地址，分别带随机参数与不带参数，查看响应头里的 Age、X-Cache、Cache-Control、ETag、Last-Modified。如果某个节点返回的 Age 很大，而页面内容早已更新，说明之前的刷新并没有覆盖到全部节点。有条件的话，再从不同地区或不同运营商访问一次，对照页面正文是否一致。
一份务实的自查清单
- 静态资源（图片、CSS、JS）是否带内容指纹，例如文件名里包含 hash 或版本号，并配置了较长的缓存时间。
- HTML 页面是否被设成了长期强缓存。列表页、资讯页通常更适合较短的缓存时间，甚至不缓存 HTML，让内容由回源决定。
- 缓存键都包含哪些维度：Host、路径、查询参数、语言或地区信息。少算一个维度，就可能把两种内容混成一份缓存。
- 带 Cookie 的请求和匿名请求是否被同等对待，避免登录用户看到游客页面，或者反过来把私人内容缓存出去。
- 后台、预览、接口、购物车这类路径，是否在规则里被明确排除在缓存之外。
- 404、301、302 这些响应有没有被缓存住。一个错误状态被边缘节点记住，可能持续给用户和蜘蛛错误信号。
- 是否配置了回源超时和失败兜底，避免回源异常时直接返回空白页。
刷新与预热要分层
内容更新后，刷新方式需要分清影响面：单条 URL 刷新最精准，但配额有限；目录刷新影响较大，容易把正常缓存一并清掉；全站刷新只在万不得已时使用。刷新完成之后，可以主动请求一次目标地址做预热，让第一个访问者不必承担回源等待。
缓存与抓取之间的关系
蜘蛛来访时不会等你走完刷新流程。刷新没做完，它抓到的可能就是旧版本；如果地址没变、内容却大幅调整，旧缓存与新页面之间还可能出现信号不一致。比较稳妥的做法是：正文更新尽量沿用原地址，把缓存刷新与内容发布放在同一个流程里；重要改动前后，用访问日志确认蜘蛛实际拿到的响应与线上一致。缓存只决定“看到什么”，并不决定是否被收录，不必把刷新当成收录手段。
把“刷新缓存”写进发布流程的固定步骤，顺序可以是：先发布到源站，再刷新，最后抽检几个 URL。
可以落地的几条习惯
- 维护一份缓存规则清单：哪些路径强缓存、哪些不缓存、各自缓存多久、最近一次改动是谁做的。
- 发布后抽检三到五个有代表性的 URL，在无痕窗口和带参数的情况下各访问一次，确认内容一致。
- 关注回源比例与命中率，如果某天突然下降，往往说明缓存键或规则被改动过。
- 把缓存配置纳入改版、换 CDN、调整域名的上线检查项，不要等用户反馈才发现问题。
缓存不是设置一次就能长期不管的事。规则、刷新方式、发布流程三者对齐之后，站点才能既保持速度，又不至于给出前后矛盾的内容。