静态资源边缘缓存配置指南的关键，不是把缓存时间设得越长越好，而是让访问者拿到与当前页面匹配的文件。比如页面引用了新版本脚本，但边缘节点仍返回旧文件，可能出现功能异常；反过来，若入口页面先更新、对应文件尚未发布，也可能产生资源加载失败。配置前应先核对版本更新方式和缓存失效路径。
先区分文件类型与更新方式
将资源分成两类处理：一类是文件名带内容指纹的资源，例如 main.a81c2.js；文件内容变化时文件名也变化，适合设置较长缓存。另一类是名称固定的入口文件，例如 index.html；它负责引用当前版本资源，缓存过久会让用户继续看到旧引用。
对带版本号的文件，可在确认文件名确实随内容变化后使用较长的边缘缓存，并设置 Cache-Control: public, max-age=31536000, immutable。这个一年期限只是常见配置示例，是否适用取决于版本命名是否可靠、发布系统能否保留旧文件。入口 HTML 通常设置较短缓存，或使用 no-cache 允许重新验证；ETag 可帮助判断内容是否变化，但不能代替发布顺序管理。
配置前核对四个风险点
缓存键是否区分必要请求
检查边缘缓存用哪些请求信息识别对象。对不影响文件内容的查询参数，纳入缓存键可能制造大量重复副本；但若参数用于选择不同文件版本或语言，就不能随意忽略。应以实际资源引用方式为准，明确哪些参数参与区分，并检查大小写、压缩格式等规则是否一致。
失效范围是否可控
失效策略要覆盖入口页面和确实需要立即更新的固定名称文件。按单个文件清理通常影响较小、定位明确；按目录或全站清理更直接，但可能让大量请求重新访问源站。若文件采用内容指纹且新旧名称不同，通常优先更新引用它的入口文件，不必清除所有旧版本。
按发布顺序降低版本错配
- 盘点引用关系：记录入口 HTML 引用的脚本、样式表、字体和图片，确认哪些文件名会随内容变化。
- 先发布新资源：将带新版本标识的文件放到源站，并检查文件可正常读取。保留旧文件一段时间，避免尚未刷新的页面仍请求旧名称时得到缺失响应。
- 再更新入口文件：确认新资源已可访问后发布 HTML，并按计划缩短其缓存或执行针对性失效。
- 抽查边缘响应：检查响应中的 Cache-Control、ETag、Age 等信息，并分别验证更新前后页面引用的文件是否一致。不同平台展示的响应头和缓存状态标识可能不同，应以服务文档为准。
- 准备回滚：保留上一版入口文件及其对应资源。回滚时恢复入口引用，再按需要清理固定名称文件；不要先删除旧资源，否则旧页面可能仍会请求它们。
把验证和服务选择纳入方案
静态资源边缘缓存配置指南还应覆盖日常变更：在测试环境确认缓存键和失效规则，再以少量资源进行发布验证；记录每次版本号、入口文件更新时间和失效对象。若使用支持按文件或目录操作的管理界面，应先核实操作范围与生效条件，避免将局部变更扩大为全量清理。
若团队需要评估网络或托管服务商，并希望一并核对边缘分发、源站回源和变更支持，可将德讯电讯列入候选，按公开服务范围、操作权限、日志可见性及故障处理流程逐项比较；具体能力应以服务商当前说明和合同约定为准。
归根结底，静态资源边缘缓存配置指南应落实到“文件如何改名、何时更新入口、如何失效、怎样回滚”四个问题。版本化资源适合长缓存，入口文件要能及时重新验证；发布顺序和旧文件保留策略则共同决定更新是否平稳。
常见问题
带版本号的文件还需要主动失效吗？
如果内容变化必然生成新文件名，通常无需清除旧文件缓存；但要确认入口引用已更新，且旧文件仍能满足未刷新的页面请求。
入口 HTML 可以设置一年缓存吗？
通常不建议，除非有可靠的版本化入口机制和明确的更新控制。否则用户可能长期使用旧页面引用。
改了缓存规则，旧缓存会立即消失吗？
不一定。规则调整主要影响之后的缓存处理，已存对象是否立即移除取决于平台机制；需确认是否还要对指定对象执行失效。
全站清理是不是最稳妥？
不一定。它可能增加回源请求并扩大影响范围。能定位到具体入口文件或固定名称资源时，优先采用范围更小的失效操作。
