页面改了用户却看到旧版本，从缓存清发到验证按什么顺序排查

网站内容已经更新但用户仍看到旧页面，通常不是改动没保存，而是请求还在命中中间缓存层的旧副本。正确的排查顺序是三问：源站变了吗？缓存层清干净了吗？验证的地址和响应头对吗？按这个顺序走，多数情况下十几分钟内就能定位问题出在哪一层，而不是盲目地把后台的缓存开关挨个拨一遍。

怎么确认源站其实已经变了

先绕开所有缓存层拿到源站的真实响应。常见做法是用带随机参数的地址直接请求源站 IP，或在请求里带上不缓存的标记，看返回的正文是不是新内容。如果源站已经是新版，问题就被压缩到缓存层；如果源站还是旧的，那就是发布环节没生效——检查文档状态是不是还停在草稿或待发布，或者改动落在另一套模板文件上。

这一步不要跳过。很多「清了缓存还是旧页」的返工，根源是最开始就没有证实源站真的更新过。尤其是做过全站替换这类批量改动的站点，替换任务是否跑完、有没有漏掉的栏目，先核对清楚再动缓存。

缓存清除有哪些粒度可用

以主流边缘服务厂商的公开文档口径为例，清缓存不是一个开关，而是一组粒度：可以按单条地址精确清除，可以按主机名清掉整个域名，可以按标签只清某一类页面，可以按路径前缀清掉一个目录，也可以一次性清空全站。选型和排障时都用得上这组概念——粒度越粗，对站点整体命中率的冲击越大。

对内容站来说，合理的默认习惯是「哪层出的问题清哪层」：单篇文章改了，就按地址清；栏目模板改了，按前缀或标签清栏目页与下面的文章页；只有在升级、迁移这类全局变更后，才用全站清空。把粗粒度当日常手段，代价是回源量和响应时间同时上升，用户体验反而受损。

站内如果依赖的是程序自身的缓存与静态文件，逻辑相同：AnQiCMS 提供全站替换工具做批量的关键词或链接改动，配套的备份能力支持把数据连同静态文件一起带走，改坏了可以整体回退，这比在缓存层反复试探更稳妥。

清完缓存怎么验证已经不再命中

验证的标准动作是看响应头。厂商文档的通用建议是：清除后再次请求同一地址，确认缓存状态头不再是命中——以 Cloudflare 这类服务的响应头为例，HIT 表示仍由边缘直接供页，MISS 或回源状态才说明新内容被重新拉取。除了响应头，还要做两项人工确认：换一个未访问过的网络环境打开页面，排除浏览器本地缓存；用带查询参数的新地址验证，排除参数被并入缓存键的旧副本。

若验证后仍是旧页，往上追一层：是不是页面地址背后还有第二级缓存，比如网关、反向代理或程序内的页面缓存；每一级都要单独清、单独验，不能假设清了边缘就等于全链路生效。

批量改动量大时怎么留回退

缓存问题之所以难排，很多时候是因为改动本身就是批量的：栏目改名、批量换链接、模板整体替换，一次牵动成百上千个地址。动手前留两步：一是数据与静态文件的备份，出问题能整体还原；二是改动清单，记下这次动了哪些地址范围，清缓存时按清单对应的粒度去清，而不是全站一炮清空。备份在 AnQiCMS 后台属于常规运维项，恢复演练时建议连上传文件一起验证，避免只备了库、丢了图。

常见问题

只清了 CDN，为什么还有人看到旧页？ 链路上可能还有浏览器缓存与程序内缓存两级，浏览器侧用无痕窗口验证，程序侧按其缓存开关单独清理。

全站清空会不会把站点清崩？ 不会导致不可访问，但短时间内全部请求都回源，响应变慢、源站压力上升，因此尽量按地址、前缀或标签这类更小的粒度清。

怎么判断该清哪一层？ 从响应头入手：返回里带哪一层的缓存状态头，就先清那一层；看不到任何缓存头时，优先怀疑浏览器本地缓存或 DNS 指到了另一台机器。