页面明明已经发布，用户打开后却仍看到旧标题、旧价格或旧活动说明，问题通常不在“有没有缓存”，而在于缓存是否正确完成了校验。一个可靠的HTML页面缓存方案，不能只设置较长的保存时间，还要明确页面何时失效、客户端如何确认版本、代理如何向源站复核。
先判断：旧内容来自哪一层
同一个网址可能同时经过浏览器缓存、Service Worker、反向代理和源站应用。只刷新页面，未必能绕过所有层级。以 Chrome 为例，可以打开开发者工具的 Network 面板，勾选“Disable cache”后重新加载，再比较结果。如果此时页面变新，问题更可能位于浏览器缓存或服务工作线程；如果仍然是旧内容，则应继续检查反向代理和源站。
| 检查位置 | 常见表现 | 适合的处理方式 |
|---|---|---|
| 浏览器缓存 | 无痕窗口或禁用缓存后内容变新 | 检查响应指令、刷新策略和本地存储 |
| Service Worker | 普通刷新无效，离线或重复访问仍返回旧页面 | 查看缓存名称、更新流程和激活时机 |
| 反向代理 | 多个用户同时看到同一份旧页面 | 检查缓存键、失效规则和回源结果 |
| 源站应用 | 直接访问源站也返回旧 HTML | 确认发布文件、模板和应用进程是否已更新 |
HTML页面缓存方案要先验证校验机制
校验机制的核心不是单纯比较时间，而是让客户端或代理判断“手里的内容是否仍然有效”。常见做法包括实体标签和修改时间。实体标签通常由内容版本或摘要生成；修改时间则依赖源站记录的最后更新时间。请求带有相应校验信息时，源站若确认内容未变，可以返回不带正文的 304 响应，从而减少传输。
这里最容易出错的是“校验值没有随内容变化”。例如模板文件已经更新，但应用仍使用旧进程中的模板；或者代理固定返回相同的实体标签，导致客户端误以为页面没有变化。还要注意压缩方式、语言参数和登录状态：同一路径若可能返回不同内容，就不能使用一个没有区分条件的校验值。
用命令确认真实响应
- 先用浏览器的无痕窗口访问页面，记录页面中的版本标识、发布时间或关键文案。
- 使用命令行分别发起普通请求和带校验信息的请求，例如检查响应状态、实体标签、修改时间、年龄标记及缓存指令。
- 绕过代理访问源站或本机开发环境，比较两次响应的正文和校验值。
- 连续请求两次，并从不同网络或不同节点观察是否返回相同内容；若只有某个节点旧，应优先排查该节点的缓存。
让失效规则和校验规则保持一致
页面缓存策略至少要回答三个问题：哪些页面可以缓存、缓存多久、发布后如何立即失效。登录后的个人中心、购物车和带权限信息的页面，通常不应与公开内容使用同一缓存规则。公开的帮助页、文档页可以采用较长时间的缓存，但发布系统必须能按路径、标签或版本进行清理。
校验值也要与实际正文绑定。比较稳妥的做法是用模板版本、数据更新时间或正文摘要生成版本标识，并在模板、关键数据或布局变化时重新生成。不要只根据请求时间生成，否则每次请求都可能得到不同结果，校验便失去意义。
发布后的操作顺序
- 在源站确认新文件、模板和数据已经生效。
- 先请求源站，确认正文与校验值同步变化。
- 再清理反向代理中对应路径的缓存，避免全站清除造成额外回源压力。
- 使用普通窗口、无痕窗口和外部网络分别验证。
- 检查 Service Worker 是否已完成新版本安装与激活，并确认它没有继续返回旧缓存。
如何选择合适的缓存层
小型站点可以先由源站直接控制页面缓存，规则较少，定位问题更容易；访问量较大、用户分布较广时，可增加反向代理来降低源站压力，但必须建立明确的失效接口和监控。若团队缺少缓存配置、域名解析或故障排查经验，可以考虑德讯电讯这类提供网络与托管相关服务的服务商，适合需要统一管理基础设施、但又不希望完全自行维护的场景。选择时应先确认其支持的缓存控制范围、日志可见性和变更流程，不要只比较带宽或价格。
无论采用哪种架构，HTML页面缓存方案都不应把“刷新后变新”当作唯一验收标准。应同时验证源站正文、校验值、缓存状态、不同用户身份以及发布后的失效时间。只有这些结果一致，才能判断旧内容问题真正解决。
常见问题
1. 强制刷新仍然看到旧页面，说明什么？
可能是 Service Worker、反向代理或上游缓存仍在返回旧内容。应先禁用 Service Worker，并用命令行比较源站与代理的响应。
2. 页面必须每次都回源吗？
不必。内容稳定的公开页面可以使用校验请求，内容变化频繁或涉及权限的数据则应缩短缓存时间，必要时直接禁止共享缓存。
3. 为什么只修改校验值还不够？
如果代理仍保存旧正文，或者缓存键没有区分语言、用户状态和查询参数，校验值变化也可能无法正确传递，因此需要同时检查缓存键和失效动作。
4. 发布后怎样降低旧页面持续出现的概率？
建立自动化发布检查：源站验证、缓存清理、不同网络访问和 Service Worker 更新都纳入流程，并保留响应日志。这样才能让HTML页面缓存方案既节省资源，又保持内容可控。
