内容分发服务如何处理缓存刷新与版本更新，关键在于先区分“内容变了”还是“文件地址变了”。图片、样式表和脚本可以使用带版本号的文件名，让新旧版本并存；HTML 入口、配置文件等经常变化的内容，则通常需要较短缓存时间或在发布后主动刷新。把所有文件一律清空缓存，既可能增加源站请求，也未必能清除用户浏览器中的旧副本。
先按内容类型决定刷新方式
| 内容类型 | 常见处理方式 | 适用考虑 |
|---|---|---|
| 带哈希或版本号的静态文件 | 生成新文件名并更新引用，旧文件保留一段兼容时间 | 适合内容变更后地址也变化的资源，通常不必清理旧地址缓存 |
| HTML 页面、清单文件 | 设置较短缓存，发布后按路径刷新 | 页面引用关系改变时，需让用户尽快取得新入口 |
| 接口返回或个性化内容 | 按业务设置不缓存或短暂缓存，并明确缓存键 | 要避免不同用户、语言或参数误用同一份响应 |
例如，应用把样式文件从 app.css 改为带内容指纹的新文件名，浏览器会请求新地址；若仍沿用原文件名，即使边缘节点已刷新，浏览器本地缓存也可能继续使用旧文件。版本化解决的是地址层面的区分，不能替代 HTML 入口的更新。
按顺序发布，避免入口先于资源
一次稳妥的操作可以拆成以下步骤。具体命令因服务商和部署工具不同而异，原则是先确保新资源可访问，再切换用户入口。
- 列出变更范围。记录新增、替换和删除的文件，以及对应页面、语言版本或设备端。确认是否存在 Service Worker 等会自行缓存资源的机制。
- 上传新版本资源。先发布带新版本号或内容哈希的图片、脚本和样式表，并从源站检查响应状态、内容类型及文件内容。
- 更新入口文件。确认 HTML、资源清单或配置已经引用新文件，再发布入口。若入口缓存较长，应准备按具体路径刷新。
- 执行定向刷新。优先清理已变更的文件路径或缓存标签。仅在范围难以确定、且影响确实广泛时考虑全站清理；全量刷新可能让大量请求集中回到源站。
- 多处验证。检查页面实际引用的文件名、响应内容和缓存响应头；从不同网络或地区复核，留意节点传播存在时间差。浏览器还可用无痕窗口或清理站点数据排查本地缓存影响。
刷新范围与缓存时间怎么取舍
定向刷新更适合小范围修正
只改一个图标或页面时，按路径清理通常更可控；若服务支持按标签刷新，可用同一发布批次的标签管理相关对象。需要注意，路径匹配规则、查询参数是否参与缓存键，以及标签覆盖范围，都取决于具体服务配置，操作前应核对规则，避免误清或漏清。
全量刷新用于范围明确的紧急情况
全量刷新适合错误内容广泛传播、缓存规则整体调整等场景，但不应作为每次发布的默认动作。大量缓存同时失效时，源站可能面对突增请求。可先确认源站承载能力，并观察请求量、错误率和响应时间；若资源文件采用版本化地址，通常只需更新入口，不必清空全部静态缓存。
缓存策略也要区分边缘缓存和浏览器缓存。CDN 的刷新一般影响其缓存副本，不一定能撤销用户设备已保存的长期缓存。因此，对可覆盖的固定地址应谨慎设置较长有效期；版本化静态文件则可设置较长缓存并声明内容不可变，前提是每次内容变化都会生成新地址。HTML 入口通常需要更短的有效期，或结合重新验证机制。
出现旧版本时的排查与回滚
如果部分用户仍看到旧页面，先判断旧内容来自哪一层：查看响应头中的缓存状态、对象年龄或验证结果，并对比页面引用的资源地址。若 HTML 还是旧的，检查入口文件刷新和浏览器缓存；若 HTML 已更新但资源缺失，检查新文件是否已上传到所有源站位置、权限是否正确，以及旧文件是否过早删除。若只有特定用户受影响，还要检查 Service Worker 或应用自身的离线缓存。
发布前保留上一版入口和资源，回滚时优先恢复已验证的入口引用，再按需要刷新相关路径。不要只把文件覆盖回旧内容却沿用可能已被缓存的地址；若同一 URL 的内容发生变化，仍需处理边缘与浏览器两侧的缓存。内容分发服务如何处理缓存刷新与版本更新，应由资源是否版本化、变更范围及回滚要求共同决定，而不是只看“刷新成功”的提示。
常见问题
刷新后为什么仍看到旧页面？
可能是浏览器缓存、Service Worker、未覆盖的缓存键或节点尚未完成更新。先检查实际响应和入口引用，再逐层排查。
每次发布都要清空全部缓存吗？
通常不需要。静态文件使用新版本地址，入口和少量变更对象采用定向刷新，影响范围更容易控制。
旧版本文件应该立即删除吗？
不宜一概而论。新入口切换后，仍可能有旧页面引用旧资源；可结合访问情况和兼容要求保留一段时间，再清理。