重庆云主机：多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8a1ea0a1e163.html
📄
重庆云主机：多层缓存返回不同版本时怎样定位一致性问题
先给结论：多层缓存返回不同版本，通常不是“缓存坏了”，而是某一层的键、过期时间或失效通知没有和其他层对齐。先找出哪一层先返回旧版本，再验证它的键和失效路径，比反复清空全部缓存更有效。
用一个假设情境把问题固定下来
假设某站点部署在重庆云主机上，前面有 CDN，中间有反向代理缓存，应用内部还有对象缓存。页面改版后，部分访客看到新标题，部分访客仍看到旧标题，刷新多次结果还会变化。常规做法已经试过：手动清空应用缓存、重启服务、重新发布静态资源，但问题仍间歇出现。这个情境的关键不是“缓存没清”，而是三层缓存的版本没有统一。
此时不要继续扩大清理范围。先记录一个可复现的请求：带上完整 URL、查询参数、请求头中的 Accept-Encoding 与 Cookie，以及响应头里的 Age、Cache-Control、ETag 或自定义缓存标识。下一步动作是：用同一请求分别绕过 CDN、绕过反向代理、直接访问应用，比较三次返回的版本标识。结果会直接决定排查方向——如果只有绕过 CDN 才一致，问题在 CDN 层；如果绕过反向代理才一致，问题在代理层。
先区分“版本不同”还是“键不同”
多层缓存最容易遗漏的条件是缓存键。表面上看是同一页面返回了不同版本，实际上不同层可能把移动端与桌面端、登录与未登录、带参数与不带参数当成不同对象。定位时先做一件事：把每层实际使用的缓存键写出来，逐项对比。
- CDN 是否把查询参数、Cookie、设备类型计入键。
- 反向代理是否按
Vary指定的请求头分别存储。 - 应用对象缓存是否把用户身份或语言拼进键。
如果三层的键不一致，就会出现“新版本写进 A 键、旧版本仍从 B 键返回”。这时清空缓存只能短暂掩盖问题，下一次请求仍会分叉。确认键一致后，再检查过期时间和失效通知，顺序不要颠倒。
用响应头判断哪一层先返回旧版本
把同一请求连续发送几次，重点看响应头而不是页面内容。假设 CDN 返回的 Age 很大，说明它命中了较旧的副本；绕过 CDN 后反向代理返回的 Age 很小，说明代理层已经更新。这个证据组合指向 CDN 未收到或未正确处理失效通知。
反过来，如果 CDN 返回的 Age 很小，但绕过 CDN 后代理层仍返回旧版本，问题就在反向代理的键或过期策略。若三层都返回旧版本，才需要回到应用层检查写入是否成功。这里要说明一个限制：请求量、抓取量或某层命中数突然归零，不能单独证明处理正确，它也可能来自流量波动、日志采样变化或监控口径调整。
失效通知的覆盖范围往往被高估
很多团队假设发布一次就会让所有层失效，实际并非如此。需要分别确认：应用是否向反向代理发送了失效请求；反向代理是否把失效传播到 CDN；CDN 是否接受该失效方式。任意一环缺失，都会留下旧版本。
一个可执行的验证是：发布后立即请求目标 URL，记录三层各自的版本标识与时间戳；等待一个过期周期后再请求一次，观察是否收敛。如果第一次不一致、第二次一致，说明失效通知不可靠但过期时间能兜底；如果两次都不一致，说明键或存储本身有问题。这个结果决定下一步是补失效链路，还是先统一缓存键。
把定位结果转成最小修复动作
定位到具体层之后，只改这一层的一个条件，并保留回退方式。例如确认是 CDN 未把查询参数计入键，就先只调整该层的键规则，再重复上面的三层对比。若版本收敛，说明判断成立；若仍分叉，继续检查下一层的 Vary 或过期时间。
还要注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这些和缓存版本一致性是不同问题，不要混在一起处理。整个排查的价值在于：把“清空所有缓存”换成“找出哪一层的键或失效路径没对齐”，这样每一步动作都能缩小范围，而不是反复回到起点。
