HTML缓存导致版本冲突的本质是浏览器加载旧版index.html，进而引用旧版资源；唯一解法是服务端禁用强缓存、启用ETag协商缓存，并确保JS/CSS等静态资源使用content-hash命名。
HTML 缓存机制导致的版本冲突，本质是浏览器加载了旧版 HTML 文件，进而加载了与之绑定的旧版 JS/CSS/资源路径，最终 DOM 结构、API 调用、状态字段全部错位。唯一可靠解法是：服务端控制 index.html 的缓存行为，禁用强缓存、启用协商缓存，并确保静态资源路径随内容变化。
为什么 Cache-Control: no-cache 必须配 ETag 或 Last-Modified
只设 Cache-Control: no-cache 不够——它只是告诉浏览器“每次用前必须校验”，但若服务端没返回 ETag 或 Last-Modified，浏览器就无法发起条件请求（If-None-Match / If-Modified-Since），结果仍是直接读磁盘缓存（200 (from disk cache)）。Nginx 默认不生成 ETag，需显式开启：
location = /index.html {
add_header Cache-Control "no-cache, must-revalidate";
etag on;
if_modified_since exact;
}
-
etag on让 Nginx 基于文件内容生成哈希值，比时间戳更精准； -
if_modified_since exact避免因系统时钟误差导致误判； - 别用
expires epoch单独替代——它只关强缓存，不触发协商流程。
为什么 meta http-equiv="Cache-Control" 在生产中无效
这个标签在现代浏览器（Chrome/Firefox/Safari）中已被完全忽略，仅对极老 IE 或某些离线文档工具起作用。你看到的“加了 meta 就生效”，往往是巧合：比如本地用 file:// 协议打开，根本没走 HTTP 头；或刚清过缓存，误以为是 meta 生效。
- 验证方式：打开 DevTools → Network → 刷新 → 找
index.html请求 → 看 Response Headers 里有没有真实的Cache-Control； - 如果 headers 为空或只有
Pragma，说明 meta 标签没起作用，且服务端配置缺失； - CDN（如 Cloudflare）会覆盖源站 header，必须在 CDN 控制台单独关闭
/index.html的缓存规则。
为什么静态资源必须带 content-hash，不能只靠 v= 参数
v=1.2.3 这类查询参数容易被 CDN、代理、甚至浏览器自身忽略或剥离，而 content-hash（如 app.a1b2c3.js）是路径的一部分，只要 URL 变，缓存就是新实体。构建工具（Vite/webpack）必须同时完成两件事：
立即学习“前端免费学习笔记（深入）”；
- 输出文件名含哈希：
build.rollupOptions.output.chunkFileNames设为static/js/[name]-[hash:8].js； - HTML 中的 script/link 标签也自动注入对应哈希路径——不能手写
v=后再手动改服务器文件，否则引用和文件不匹配； - Service Worker 若缓存静态资源，缓存名（如
assets-v2.1.0）也得带构建哈希，否则 activate 阶段无法识别并清理旧桶。
为什么企业微信里问题更顽固
企业微信内置 WebView 对 index.html 有额外强缓存策略：首次加载后，即使你发版、改了服务端 header，它仍可能从本地缓存读取 HTML，直到用户手动下拉刷新或杀进程重进。此时单靠服务端配置不够，需叠加客户端兜底：
- 在 HTML 中内联一个构建版本号：
window.__APP_VERSION__ = "v2.3.1-abc123"； - 启动时比对 localStorage 中存的上一次版本，不一致则调用
location.reload(true)（强制跳过缓存）； - 避免用
fetch检查/version.json再 reload——该请求本身也可能被缓存，得加cache: 'no-store'且带随机 query（如?t=123456789）。
真正卡住的从来不是某一行代码，而是 HTML 缓存头没生效 + 静态资源路径没变 + 企业微信 WebView 的双重缓存叠加。三者缺一，版本冲突就还在。
