资源已经分发到用户附近，却仍出现旧样式、脚本加载失败或缓存命中率偏低，问题往往不在距离，而在缓存键与版本更新没有配合好。设计网站静态资源就近分发方案时，应先明确：哪些请求可以共用缓存，资源更新后又如何让新旧页面都能正常工作。
先把缓存键定义清楚
缓存键是缓存系统用来区分请求的标识，通常由主机名、路径以及指定的查询参数或请求头组合而成。两个请求只要缓存键不同，就可能分别存储；键过于宽泛，则可能把不该共享的内容交给其他请求。
以公开文档站点为例，同一张插图若只因网址带有不同的统计参数就生成多份缓存，会降低复用率。可以在确认参数不影响响应后，配置缓存忽略已知的追踪参数；但尺寸、语言或格式确实会改变内容的参数，不能一概删去。若源站根据请求头返回不同版本，还要检查响应中的 Vary 设置与缓存规则是否一致。
静态文件通常不需要按登录 Cookie 区分缓存。只有响应确实因 Cookie 或授权状态而变化时，才应设计相应隔离规则；否则将这类字段纳入缓存键，容易造成缓存条目碎片化。网站静态资源就近分发方案的缓存键，应与源站实际内容变化条件保持一致，而不是把所有请求字段都塞进去。
版本更新要让新旧资源并存
优先考虑内容哈希文件名
将文件内容摘要写入文件名，例如把主样式文件命名为 app.4f2a.css，是常见的版本管理方式。文件内容变化时生成新名称，旧名称仍指向旧内容。对这类不可变资源，可使用较长的浏览器与边缘缓存时间；常见配置示例是 Cache-Control: public, max-age=31536000, immutable。这个时长适合文件名确实随内容变化的场景，不适合仍会原地覆盖的固定路径。
另一种做法是在网址中加版本查询参数。它容易接入现有构建流程，但前提是分发层把该参数纳入缓存键；如果缓存规则忽略它，网址虽然变了，边缘节点仍可能返回旧文件。相比之下，内容哈希路径更直观，但需要部署系统同步更新引用关系。
发布顺序比单次清缓存更重要
- 先上传新资源。确认文件已能从源站读取，并检查文件名与页面引用一致。
- 再发布引用新资源的 HTML。HTML 可采用较短缓存时间，或要求缓存重新验证；具体策略取决于页面更新频率。
- 保留旧版本一段时间。浏览器中尚未更新的页面可能继续请求旧文件，过早删除会造成 404。保留时长应结合页面缓存时间、部署节奏和回滚要求评估。
- 最后处理缓存失效。只清理确实需要立即更新的固定路径内容，并抽查不同节点和浏览器的响应头、文件版本与状态码。
这套顺序让新页面先获得可用的新文件，也给旧页面留出读取旧文件的窗口。对固定文件名进行覆盖时，清边缘缓存并不一定能同步清除用户浏览器里的副本，因此版本化通常更容易控制。完善的网站静态资源就近分发方案，应同时管理边缘缓存、浏览器缓存和源站文件保留周期。
上线前按请求链路检查
- 列出资源路径、影响内容的参数和响应头，逐项确认缓存键。
- 用开发环境发布一次新版本，验证 HTML 是否引用新文件，旧文件是否仍可访问。
- 分别请求带追踪参数与内容参数的地址，确认前者按预期复用缓存，后者不会拿到错误变体。
- 检查缓存状态、Cache-Control、ETag 或 Last-Modified 等响应信息；不同平台字段名称可能不同。
- 准备回滚路径：恢复上一版 HTML，并确保其引用的资源尚未删除。
评估网站静态资源就近分发方案时，不要只看命中率或单次加载速度。还要观察更新后是否出现旧文件、错误变体或请求失败，并将发布与缓存规则纳入同一份变更清单。
常见问题
缓存键包含所有查询参数更安全吗？
不一定。只保留会改变响应内容的参数；无关参数可能制造重复缓存，忽略关键参数则可能返回错误内容。
改了文件内容，清缓存够不够？
如果使用固定路径，清理相关缓存可能有帮助，但浏览器已有副本仍可能存在。内容哈希文件名能更明确地区分新旧版本。
旧资源应该保留多久？
没有适用于所有网站的固定时长。应至少覆盖页面缓存、用户打开页面到发起资源请求的时间，以及常见回滚窗口。
静态文件适合设置很长的缓存时间吗？
适合内容版本明确、文件名随内容变化且旧文件仍可访问的资源；原路径会被覆盖的文件应采用更谨慎的缓存策略。
归根结底，网站静态资源就近分发方案的稳定性，取决于缓存键是否准确、版本是否可区分，以及发布时是否照顾新旧页面。把这三项一起验证，才能让就近缓存既快，也能可靠更新。
