静态资源“持久化”本质是URL稳定+服务端正确配置Cache-Control等响应头，核心在于内容不变则哈希不变、HTML与对应哈希资源原子性发布、CDN透传缓存头，四者协同才能实现高命中率长期缓存。
静态资源链接本身不“持久化”，真正起作用的是浏览器对 Cache-Control、ETag 等响应头的缓存行为；所谓“持久化链接”只是指 URL 不变、内容可被长期缓存——一旦 URL 改变，缓存就失效。所以优化核心不是改链接写法，而是让链接稳定 + 服务端配对正确缓存策略。
如何让 CSS/JS 链接真正“持久化”且被复用
很多团队给静态资源加哈希（如 main.a1b2c3.js）后仍出现缓存未命中，问题往往不在文件名，而在服务端没配好响应头或构建流程破坏了稳定性。
- 确保每次构建时，**内容不变则哈希不变**：Webpack/Vite 默认启用 contenthash，但若配置了动态
require.context或拼接了环境变量字符串，会导致无意义变更 - 静态资源响应头必须包含
Cache-Control: public, max-age=31536000（1年），且不能带no-cache或must-revalidate（除非你真需要强制校验） - 避免在 HTML 中用
timestamp或version=1.2.3这类参数拼接资源 URL（如app.js?v=1.2.3），它会绕过强缓存，且无法利用 HTTP 缓存协商机制 - CDN 节点需透传或重写响应头：有些 CDN 默认覆盖
Cache-Control，需显式配置保留或覆盖为合理值
HTML 中引用静态资源的写法陷阱
即使资源本身已缓存，HTML 的引用方式仍可能破坏复用效果，尤其在 SSR 或构建产物注入场景下。
-
<link rel="stylesheet" href="/css/main.css">这种写法没问题，但若构建后实际路径是/css/main.8f9a2d.css，而 HTML 里硬编码了旧路径，缓存就形同虚设 - Webpack 的
html-webpack-plugin会自动注入带哈希的资源路径，但若你手动在模板里写死href或用process.env拼接，就可能漏掉哈希 - SSR 框架（如 Next.js/Nuxt）默认在 HTML 中内联 critical CSS，但非关键 CSS 若用
<link>引入，需确认其href是由构建系统生成的稳定路径，而非运行时拼接
为什么改了资源链接却没更新到用户端
常见现象是开发者本地刷新看到新样式，但用户打开仍是旧版——这通常不是 CDN 缓存问题，而是 HTML 文件本身没更新，导致浏览器继续请求旧哈希的 JS/CSS。
立即学习“前端免费学习笔记（深入）”；
- HTML 文件必须和它引用的静态资源**原子性发布**：即一次部署中，HTML 和对应哈希的 JS/CSS 同时上线。否则会出现 HTML 指向旧哈希文件，而该文件已被 CDN 清除或覆盖
- HTML 自身应设较短缓存周期（如
Cache-Control: public, max-age=600），避免它成为更新瓶颈；部分团队误设为 1 年，结果改了 JS 用户也看不到 - 检查 Network 面板中 HTML 响应头：若返回
304 Not Modified，说明 HTML 没变，那它引用的资源自然也不会变
真正难的不是生成带哈希的文件名，而是让 HTML、资源文件、CDN 缓存、服务端响应头四者节奏一致。一个环节脱节，整个“持久化”就断在中间。
