URL提交，多层缓存返回不同版本时怎样定位一致性问题
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ea9b803e924d.html
📄
URL提交，多层缓存返回不同版本时怎样定位一致性问题
先做一次带唯一标记的请求，把同一条URL在每一层缓存里的响应分别取出来，比较标记是否一致。缺少CDN权限或日志时，这个动作仍然能做：用查询串加随机值绕过缓存，或从不同网络出口请求，记录返回的版本标识。如果各层拿到的版本不同，问题通常在缓存键或刷新顺序，而不在提交动作本身。
先确认差异是版本问题还是缓存命中差异
多层缓存下，同一URL可能经过浏览器缓存、CDN边缘节点、反向代理和源站。不同层返回不同内容，有两种原因：一是各层存了不同时间点的副本，二是各层的缓存键计算方式不同，把同一URL拆成了多个键。区分方法很直接：给URL加一个每次变化的查询参数，强制穿透所有缓存回到源站，看源站当前输出是什么。再用不带参数的URL请求，看各层返回什么。如果带参数的结果一致、不带参数的结果分裂，说明源站只有一个版本，分歧出在缓存层。
反过来，如果带参数穿透后各出口拿到的源站结果仍不一致，那问题在源站本身，比如多台源站服务器之间的文件同步延迟，或者灰度发布只更新了部分节点。这一步的结论会决定下一步查哪里，所以不要跳过。
用缓存键和响应头判断分歧发生在哪一层
缓存键决定了哪些请求被视为同一个对象。常见的影响因素包括：主机名是否带www、协议是HTTP还是HTTPS、是否忽略查询串、是否按Cookie或设备类型分流、是否区分Accept-Encoding。任何一项在不同层配置不一致，就会产生两个缓存条目，各自返回自己那份副本。
可执行的判断动作是逐层看响应头。重点看缓存命中状态、缓存年龄、以及源站返回的缓存控制指令。假设源站对某页设置了较短的缓存时间，而CDN层被配置成较长缓存，那么源站更新后，CDN仍会继续返回旧副本直到过期。此时各层版本不同是预期行为，不是故障，需要做的是等过期或主动刷新，而不是反复重新提交URL。
如果响应头显示某层完全没有缓存标记，而它又确实在返回内容，说明这一层可能是直接透传或另有代理，需要单独确认它的角色，否则会把透传层误判成缓存层。
缺少权限时仍能做的最小验证
没有CDN后台和源站日志时，仍然可以收集可比较的证据：
- 从至少两个不同网络环境请求同一URL，记录返回内容中的版本标识、时间戳或资源指纹。
- 对同一URL分别带随机查询串和不带查询串请求，对比结果，判断是否存在缓存分流。
- 检查页面引用的静态资源文件名是否带内容指纹，指纹不同就意味着版本不同。
- 记录每次请求的时间，观察旧版本是否在某个时间点后自动消失，以此推断缓存过期时间。
这些动作能回答“分歧在哪一层、是否会自动收敛”，但不能回答“哪一层配置错了”，因为看不到配置本身。这个边界要明确，不要用观察结果去反推一个自己无法验证的配置结论。
假设例子：一次标记对比怎么读结果
假设某页面在源站更新后，你在页脚加了一个版本标记。从办公网络请求，返回新标记；从移动网络请求，返回旧标记；带随机查询串请求，两个网络都返回新标记。这组结果指向：源站已是新版本，不带参数的请求被某层缓存拦截，且该缓存对不同网络出口返回了不同副本。下一步应当是确认这层缓存的键是否包含网络出口相关维度，以及它的过期时间，而不是重新提交URL或修改源站。
如果带随机查询串时两个网络仍然一个新旧一个旧，那么缓存不是唯一变量，需要转向源站多节点一致性或发布流程本身。
处理顺序与不能推出的结论
合理的顺序是：先确认源站当前版本，再确认分歧层，再判断是缓存过期问题还是缓存键问题。缓存过期问题可以等或主动刷新；缓存键问题需要统一各层的键计算规则，否则刷新一次后还会再次分裂。
需要克制的推论：某次请求返回旧版本，不能直接断定提交动作失败；某层缓存命中率下降，也不能单独证明配置改对了，它也可能是流量结构变化或键维度增加导致的。抓取或请求量归零同样有多种解释，包括请求路径改变、统计口径变化或采集延迟，不能作为一致性已修复的证明。把观察到的现象和能验证的配置分开记录，才能让下一步动作有依据。
