静态资源边缘缓存配置的难点，不是把缓存时间设得越长越好，而是区分“内容是否会变”。图片、字体、脚本和样式表可以长期复用；承载资源清单的 HTML 则需要及时反映新版本。把这两类文件分开处理，能减少旧资源与新页面错配。
先用内容版本区分新旧文件
推荐为构建产物加入内容哈希，例如把 main.js 输出为 main.a83f2c.js。文件内容改变，哈希随之改变，边缘节点会把新文件视为独立对象；未改变的文件仍沿用原地址，继续命中已有缓存。这种内容哈希方式通常比覆盖同一路径更可靠。
对带哈希的文件，可设置较长的共享缓存时间，并在确认地址不可变时使用 immutable 指令。HTML 入口文件则采用短缓存，或要求缓存节点重新验证源站版本。这样更新 HTML 不必清空所有图片、字体和脚本缓存。
缓存键要保留真正影响内容的部分
缓存键决定哪些请求共用一份缓存。若图片地址的宽度参数会改变输出尺寸，就不能随意从缓存键中删除该参数；如果统计参数不影响文件内容，则可在确认业务逻辑后忽略它，避免同一资源因无关参数产生大量副本。查询参数规则应按文件类型分别核查。
发布目录、语言版本或压缩格式也可能影响响应内容。检查时对比请求路径、必要参数、响应头和返回文件，确保不同内容不会误用同一缓存对象。反过来，若参数虽多但都不改变响应，可通过白名单方式只保留必要项，提升缓存复用率。
按资源类型设置策略
| 资源 | 建议策略 | 注意事项 |
|---|---|---|
| 带哈希的 JS、CSS | 较长缓存期，内容变化时生成新文件名 | 确认 HTML 引用的是当前构建版本 |
| 图片与字体 | 稳定地址可缓存较久；变化时改名或带版本 | 字体跨源使用时检查 CORS 响应设置 |
| HTML 入口 | 短缓存或重新验证 | 避免旧清单引用已删除的文件 |
缓存时间没有适用于所有站点的固定值。对于带内容哈希、可长期保留的静态文件，常见配置会采用数周至一年左右的缓存期限；频繁更新且不能版本化的资源，应缩短期限。实际取值还要考虑发布频率、回滚要求和边缘服务商的规则。
用可回滚的顺序发布
- 生成新资源。构建后检查文件名是否包含版本或内容哈希，并确认 HTML 清单引用完整。
- 先上传资源。将新脚本、样式、图片和字体发布到源站，确认可正常读取，再切换 HTML。
- 更新入口文件。发布新 HTML，并检查边缘节点返回的资源地址是否属于同一版本。
- 验证缓存结果。分别请求新旧地址，观察状态码、缓存命中信息和响应内容；关键资源可从不同地区抽查。
- 保留旧文件并准备回滚。确认新版本稳定后再按保留策略清理旧资源；若需回滚，恢复旧 HTML 时，旧资源仍应可访问。
如果必须覆盖固定路径，可对单个资源执行定向失效，并确认失效已传播，再检查回源结果。大范围清除会让大量请求重新访问源站，容易造成不必要的回源压力。静态资源边缘缓存配置应优先依靠版本化更新，失效操作用于修正例外，而不是每次发布的默认步骤。
常见问题
文件内容更新了，为什么用户仍看到旧版？
常见原因是地址未变化、HTML 入口仍被缓存，或失效规则没有覆盖实际缓存键。先核对页面引用地址，再检查响应头和缓存键设置。
只改查询参数能不能区分版本？
可以，但前提是边缘缓存确实把该参数纳入缓存键。若规则忽略查询参数，不同版本可能仍命中同一对象；内容哈希文件名更直观。
缓存时间设长后，紧急修复怎么处理？
优先发布带新版本地址的文件并更新入口；固定路径资源则定向失效，并验证不同边缘节点已获取新内容。
旧版本文件要保留多久？
至少覆盖页面缓存、用户打开旧页面及回滚所需的时间。具体周期应根据站点更新节奏和回滚流程设定，而非一律立即删除。
归根结底，静态资源边缘缓存配置要让内容版本承担更新职责，让缓存键准确区分响应，再用分阶段发布和定向失效处理例外。这样既能复用未变化的文件，也能让新版本按预期到达用户。