给站点接入 CDN 之后，访问速度通常会有明显改善，但也会带来一类不容易察觉的问题：页面明明已经改过，访客看到的还是旧版本；某些地区的节点返回内容和源站不一致；蜘蛛抓到的页面和当前实际内容对不上。这些情况未必是 CDN 出故障，更多时候是缓存策略和内容更新流程没有对齐。
先弄清楚谁在缓存什么
CDN 缓存的对象不只是 HTML。图片、CSS、JS、字体文件、接口返回的 JSON，甚至错误页面都可能被缓存。不同类型资源的合理缓存时长差别很大：带版本指纹的静态资源可以放心缓存较长时间；HTML 通常需要较短缓存，或者配合主动刷新；接口数据则要更谨慎，尤其是和登录态、库存、价格相关的内容。
还要区分浏览器缓存和 CDN 边缘缓存。两者叠加时，排查会变得更麻烦——你刷新了 CDN，访客本地可能还留着旧文件；你让访客清了浏览器缓存，边缘节点上可能还是旧的。
常见的缓存问题
- HTML 被设置了过长的缓存时间，内容更新后访客仍看到旧页面。
- 错误状态码被缓存，比如 404、500 被节点记住，源站修好后依然返回错误。
- 带查询参数的 URL 被当成完全不同的资源，缓存碎片化，命中率低。
- 个性化内容或登录态页面被缓存，不同用户看到同一份数据。
- 只刷新了部分节点，出现新旧内容并存的过渡状态。
这些问题单独看都不算严重，但叠加在一起，很容易演变成“我明明改了，为什么没生效”的反复拉扯。
一份可执行的检查清单
- 列出需要缓存和不应该缓存的资源清单，写清楚每类的预期缓存时长。
- 查看响应头：Cache-Control、Expires、ETag、Vary、Age 等字段是否符合预期。
- 用不同地区、不同网络环境访问同一 URL，对比返回内容和响应头。
- 查看回源日志，关注回源比例和回源原因，判断是否异常。
- 确认刷新和预热流程可执行，知道在哪里操作、大概多久生效。
- 检查错误页、跳转页是否被缓存，避免旧状态长期驻留。
刷新动作要跟着更新节奏走
发布新文章、修改标题描述、更换模板或调整栏目结构之后，最好有明确的刷新动作，而不是“改完就等它自己过期”。常见做法是让 HTML 使用较短的边缘缓存时间，配合发布后主动刷新；静态资源则用文件名或路径加版本号，实现新版本自然生效、旧版本自然淘汰。
如果站点内容更新频繁，可以把刷新流程写进发布清单，谁改内容、谁负责刷新、多久确认一次，都提前说清楚，避免依赖个人记忆。
回源压力和蜘蛛抓取的关系
缓存命中率低，意味着蜘蛛每次抓取都要回源，源站压力大、响应变慢，抓取频率也可能受影响。合理的缓存设置能减少不必要的回源，让源站把资源留给真正需要的请求。但反过来，也不该为了降低回源就把不该缓存的内容缓存住，尤其是错误页和个性化页面。
缓存的目标是让正确的内容更快到达访客和蜘蛛，而不是把问题暂时藏起来。
换 CDN 服务商、增加节点、调整源站结构之后，建议重新过一遍上面的清单。缓存策略不是一次配置就永久有效的东西，它会随着站点结构、内容节奏和技术栈一起变化。把它当成站点运营里的常规检查项，比出了问题再临时排查要从容得多。