HTML 必须保持固定路径（如 /index.html）并用 Cache-Control 协商缓存，JS/CSS 等静态资源才应加 contenthash 后缀并配 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 和浏览器必须配合设置强缓存：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 匹配
.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 被禁用时完全失效，不能当作主缓存策略
真正的版本控制起点和终点都在服务端缓存策略与构建流程协同上，前端任何“补丁式”校验都只是辅助，不是主干。
