遇到页面内容、状态码或访问结果与预期不一致时,先不要急着改配置或提交工单。最稳妥的做法是:用不同网络、不同设备、带随机参数的URL分别请求同一资源,对比响应头中的缓存相关字段和实际返回内容,确认你看到的是源站结果还是中间缓存留下的旧副本。只有排除缓存层,才能判断问题出在托管环境、源站程序还是本地网络。
缓存假象的典型表现是:同一URL在不同网络下返回不同内容,或者刷新后内容变化、换设备后恢复正常。判断方法不是反复按刷新键,而是做对照请求。
?t=20240101a,让缓存键发生变化。Age、Cache-Control、Expires、ETag、Last-Modified 等字段。如果加随机参数后内容立刻变新,而原URL仍旧是旧内容,说明中间某一层缓存仍在提供旧副本。此时可以初步判定为缓存问题,但还不能确定是哪一层缓存。
缓存假象可能来自多个层级,排查时要逐层剥离,而不是一次性清空所有缓存。
判断顺序建议从最外层开始:先确认浏览器,再确认CDN,最后确认源站。每一层都用相同的对照方法,避免同时改动多个变量。
仅凭页面外观判断缓存并不可靠,应保留可核对的证据。可以用浏览器开发者工具的Network面板查看请求的响应头,也可以用命令行工具请求并保存结果。
重点核对以下信号:
X-Cache、CF-Cache-Status、Age 等缓存状态字段。不同服务商的字段名称不同,需要按实际返回内容判断。Cache-Control 是否允许中间缓存保存该资源,以及保存时长是多少。ETag 或 Last-Modified 是否随内容更新而变化。如果内容已更新但这些值未变,缓存层可能继续使用旧副本。把这些信息按时间顺序记录下来,才能判断问题发生在哪一层,而不是凭感觉反复清理缓存。
清理某一层缓存后,不要只看一次刷新结果。验收时应满足以下条件:
Age 归零或明显减小。如果清理缓存后问题反复出现,说明缓存配置或源站更新机制存在持续性问题,需要检查缓存规则、刷新策略和内容发布流程,而不是继续重复手动清理。
缓存假象容易掩盖其他问题。如果出现以下情况,应把排查范围扩大到缓存之外:
把缓存当作唯一解释,容易遗漏真正的故障点。每次只验证一个假设,用对照结果决定下一步。
下一步可以这样做:选取一个出现异常的具体URL,分别在无痕窗口、手机热点和带随机参数的请求下各取一次响应头和返回内容,记录三者差异。如果只有原URL异常,优先检查CDN或反向代理缓存规则;如果三者都异常,转向源站程序和托管环境排查。