HTML不能加contenthash后缀，因其是入口文档，改名会导致路径失效、SEO断链、PWA错乱；应保持固定路径并用no-cache+ETag协商缓存，而JS/CSS等静态资源才需加哈希配immutable强缓存。
HTML 里不能直接加 contenthash 后缀
给 index.html 改名成 index.a1b2c3.html 是错的——它不是静态资源，而是每次发布都可能变的入口文档。改名会导致所有相对路径失效、SEO 断链、PWA 清单错乱，且浏览器根本找不到新文件。
真正该做的，是让 HTML 保持固定路径（如 /index.html），但通过 HTTP 缓存头强制它不长期缓存：
-
Cache-Control: no-cache, must-revalidate或max-age=0 - 配合
ETag或Last-Modified实现协商缓存 - 确保用户每次打开页面，都能拿到最新 HTML，从而加载到对应的新 JS/CSS 哈希路径
JS/CSS 等静态资源必须带哈希并配 immutable
只有 JS、CSS、图片这类内容不变就绝不更新的资源，才适合加哈希后缀，比如 main.f8494f81.js。构建工具（Webpack/Vite/Sails.js）会在打包时自动生成这类文件，并输出 manifest.json 映射关系。
CDN 和浏览器必须配合设置强缓存：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 匹配
.js、.css、.png等路径，设置Cache-Control: public, max-age=31536000, immutable -
immutable的作用是告诉浏览器：这个 URL 永远不会变内容，不用发If-None-Match请求 - 如果 CDN 缓存没刷新，问题不在 HTML，而在你没按哈希路径配置 CDN 缓存规则（比如漏了
/*.f[0-9a-f]{8}.*\.(js|css)正则）
HTML 中的资源引用要自动替换，不能手写哈希
写死 <script src="main.f8494f81.js"></script> 是维护噩梦。构建阶段必须用自动化手段注入正确路径：
- Sails.js 用
sails-linker任务扫描 HTML 并替换<script>标签 - Webpack 用户用
HtmlWebpackPlugin+html-webpack-plugin插件自动注入 - Vite 用户靠
import.meta.env.BASE_URL或构建时transformIndexHtml钩子处理 - 手动替换只适用于极简场景，且每次构建后必须重新校验所有
href/src是否匹配当前manifest.json
LocalStorage 存指纹只能做增量校验，不能替代 HTTP 缓存
把 manifest.json 读进 localStorage，再比对资源哈希决定是否重载，这招能减少部分请求，但有明显局限：
- 首次访问或清缓存后，
localStorage为空，仍需全量加载 - 哈希一致 ≠ 内容一致（比如服务端文件被覆盖但哈希未变）
- 必须搭配服务端
buildId或时间戳兜底，否则旧指纹会锁死旧资源 - 跨域、隐身模式、Storage 被禁用时完全失效，不能当作主缓存策略
真正可靠的版本控制，始终依赖构建时生成哈希 + HTTP 缓存头协同，localStorage 只是锦上添花的优化层，不是根基。
