html不能加contenthash后缀，因其是入口文档，改名会导致路径失效、seo断链、pwa错乱；必须用no-cache+etag协商缓存，而js/css等静态资源才应加哈希并配immutable强缓存。
HTML 页面本身不能加 contenthash 后缀——这不是配置问题，而是架构前提错误。强行改名会断掉相对路径、毁掉 SEO、让 PWA 的 manifest.json 和 service-worker.js 失效，且根本解决不了“用户卡在旧 HTML 就加载不到新 JS”的核心矛盾。
为什么 HTML 不能像 JS/CSS 那样加 contenthash
HTML 是入口调度器，不是静态资源。浏览器永远请求 /index.html 这个固定路径；一旦你把它改成 /index.a1b2c3.html，就得同步改：Nginx 路由规则、CDN 回源路径、PWA 的 precache 列表、所有 <a href></a> 和 <script src></script> 中的硬编码路径——维护成本爆炸。
更关键的是：哪怕你在构建时把 <script src="app.d41d8c.js"></script> 写进 HTML，只要这个 HTML 文件被强缓存住（比如 Cache-Control: max-age=31536000），浏览器就再也不会重新拉它，自然也就看不到新的哈希值，新 JS 永远不会加载。
- 常见错误现象：
index.html在 Network 面板显示200 (from memory cache)，但页面功能异常或 JS 报错 - DevTools 中能看到
app.oldhash.js被加载，而服务端早已部署了app.newhash.js - 手动清空缓存或强制刷新才恢复正常——说明缓存链第一环已断裂
HTML 必须用 no-cache + ETag 协商缓存
正确做法是让服务器对 HTML 响应返回协商缓存头：既避免强缓存导致页面陈旧，又不浪费带宽重传整个文件。Nginx 示例配置：
location ~* \.html$ {
add_header Cache-Control "no-cache, must-revalidate";
add_header ETag "";
expires epoch;
}
no-cache 不等于“不缓存”，而是强制每次发起条件请求；ETag 应由服务端基于文件内容生成（推荐 md5 或 crc32），比 Last-Modified 更可靠——因为 HTML 可能频繁更新 meta、标题、内联脚本，但内容没变时，ETag 不变，返回 304 Not Modified。
- 验证方式：DevTools → Network → 刷新 → 看
index.html请求的 Response Headers 是否含ETag，Status 是否出现304 - 不要依赖
<meta http-equiv="Cache-Control">：现代浏览器完全忽略它 - 若用 CDN，需确认其支持透传或重算
ETag，否则可能返回固定值导致失效
JS/CSS 等静态资源必须带 contenthash 并配 immutable
这些文件内容稳定、体积大、复用率高，适合构建时生成 contenthash 实现长期强缓存。Webpack 配置示例：
output: {
filename: "[name].[contenthash:8].js",
chunkFilename: "[name].[contenthash:8].chunk.js"
}
Vite 默认开启 build.rollupOptions.output.entryFileNames 带 hash。配合 Nginx 强缓存策略：
location ~* \.(js|css|woff2|png|jpg|gif)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
immutable 很关键：它告诉浏览器“这个 URL 永远不会变内容”，后续访问跳过 If-None-Match 校验，省一次 RTT。但前提是 URL 真的不变——所以必须靠构建阶段注入 contenthash，而非运行时拼接。
- 8 位
contenthash足够区分变更，过长反而增加 CDN 路径长度和 DNS 查询开销 - 不要对所有资源统一用
[hash]：它基于整个构建 hash，一个文件变，所有文件 hash 都变，失去精准缓存意义 - 字体、图片等二进制资源同样适用该策略，但注意
woff2等格式压缩率高，contenthash更敏感
Service Worker 如何利用指纹做精准资源治理
SW 不是简单缓存代理，而是以指纹为单位管理资源生命周期。关键动作发生在 install/activate/fetch 三个阶段：
- install 阶段：读取构建产出的
asset-manifest.json（记录"main.js": "a1b2c3d4"映射），打开新缓存空间（如caches.open('cache-v2.3.1')），调用addAll()加载全部指纹路径 - activate 阶段：遍历
caches.keys()，删除不含当前版本号的旧缓存（如cache-v2.2.0），避免跨版本污染 - fetch 拦截中：对 HTML 请求，fetch 最新 HTML 后解析其
<script></script>和<link>，提取指纹路径；对比本地 manifest，若发现未知指纹，触发静默更新流程（如skipWaiting()+claim()） - 对静态资源请求（如
/static/app.xzy789.js）：直接cache.match()，未命中则 fetch 并存入当前指纹缓存，同时记录该指纹为“已知有效”
真正容易被忽略的是：指纹校验必须前置到构建阶段，且 SW 的缓存命名要与构建版本强绑定。如果只靠运行时计算哈希，或缓存名写死为 my-cache，就退化成普通缓存，失去版本隔离能力。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
