刚接入 CDN，先别急着把所有文件都设成长期缓存。配置CDN加速静态资源的配置与缓存规则，第一步是分清哪些内容可以复用、哪些内容必须及时更新。CSS、JavaScript、图片和字体通常适合缓存；HTML 页面则可能包含最新内容，不宜直接套用同一条长缓存规则。
先按文件用途分组
不要仅凭扩展名决定缓存时长，还要看文件的更新方式和 URL 是否变化。可先检查站点实际加载的资源，再把规则分成以下几类：
- 带版本号的资源：如 main.a83d1c.js、theme.v4.css。内容更新时文件名也改变，旧文件可继续被旧页面引用，因此通常适合较长缓存。
- 文件名固定的资源：如 logo.svg、app.js。替换文件后 URL 不变，缓存节点可能继续提供旧版本，应设置较短缓存，或在发布时主动刷新。
- HTML 页面：页面常会引用最新资源，适合不缓存、短缓存，或依照登录状态、Cookie 等条件谨慎配置。
这一步决定后续规则是否安全。长期缓存与文件名版本化配合较好；如果部署流程不会改变文件名，就不要只靠浏览器刷新来保证 CDN 节点同步。
用响应头建立基础规则
先查看源站返回的 Cache-Control。常见的 max-age 表示浏览器可缓存的秒数；CDN 是否遵循它，还取决于服务商规则和源站响应头优先级。对于内容指纹明确、URL 随内容变化的 JS、CSS、图片或字体，可从数周到一年作为配置参考，具体应结合发布和回滚流程调整。文件名固定的资源，可先从几分钟到数小时的较短周期开始观察。
例如，版本化文件可以使用类似 Cache-Control: public, max-age=31536000, immutable 的策略；其中一年是常见的示例时长，并非所有资源都必须如此设置。固定文件名的 logo 则可使用较短的 max-age，或在替换后执行 CDN 刷新。HTML 可按业务需要设置短时缓存，也可使用 no-cache，让缓存保存副本但在使用前向源站验证；no-store 则表示不应存储，适用于不希望被缓存的响应。
按顺序配置并验证
- 打开浏览器开发者工具的 Network 面板，重新加载页面，记录资源 URL、状态码和响应头，重点检查 Cache-Control、ETag 与 Last-Modified。
- 在 CDN 控制台为静态资源路径建立规则，例如针对 /assets/ 下的版本化文件；再单独处理 HTML 和不应缓存的接口响应。确认规则优先级，避免宽泛规则覆盖细分规则。
- 选择测试文件，通过命令行或浏览器连续请求同一 URL，检查响应头中的缓存状态标记。首次请求可能回源；后续是否命中，应以该 CDN 提供的响应头和日志为准。
- 发布一个内容确实改变的测试文件，观察新旧 URL 的返回结果。若 URL 没变，执行单文件刷新并确认刷新范围；若使用版本化文件，则让页面改为引用新文件名。
- 在不同网络或地区抽查结果，并检查字体等跨域资源是否允许页面所在源访问。遇到不一致时，先核对 CDN 是否忽略查询参数、是否按 Cookie 分缓存，以及源站头部是否与控制台规则冲突。
规则之外，还要管好缓存键
缓存键决定哪些请求会被视为同一份内容。若资源确实会随查询参数变化，例如不同参数返回不同尺寸的图片，就不能随意忽略参数；若参数只是统计标记，是否排除应先确认不会改变响应内容。Cookie 通常不应无差别加入静态资源缓存键，否则会产生大量独立缓存；但个性化内容也不能因此被错误共享。
缓存未命中时，CDN 通常需要向源站回源获取文件。上线前检查源站是否能稳定返回资源，并确认刷新、删除和回滚的处理方式。CDN加速静态资源的配置与缓存规则，核心不是把缓存时间设到最长，而是让文件更新机制与缓存策略一致。
常见问题
改了文件，为什么访问到的还是旧版本？
如果 URL 未变化，浏览器或 CDN 可能仍持有旧副本。优先使用带版本号的新文件名；不能改名时，再按平台提供的方式刷新对应 URL。
CDN 命中后，源站改动会立刻生效吗？
不一定。已有缓存可能持续到过期，也可能因刷新规则提前失效。具体行为取决于 CDN 的缓存策略和源站响应头。
静态资源能否全部设置一年缓存？
不建议一概而论。只有 URL 能随内容更新而变化、且发布流程能管理旧文件时，长缓存才较稳妥；固定 URL 应缩短时长或配合刷新。
