根本防不住——HTML 本身不决定缓存，浏览器是否加载旧 index.html 完全取决于服务端响应头和客户端 WebView 实现；必须在 Nginx 中对 /index.html 单独配置 Cache-Control: no-cache, no-store, must-revalidate 等响应头，并配合 HTML 文件哈希化与 PWA 正确激活，才能确保用户加载最新版本。
根本防不住——HTML 本身不决定缓存，浏览器是否加载旧 index.html，完全取决于服务端返回的响应头和客户端 WebView 的实现。你改了 JS、CSS、Vue 组件，用户却还在跑老 index.html，那所有新代码都白搭。
为什么强制刷新（Ctrl+F5）解决不了生产问题
开发阶段按 Ctrl+F5 能绕过缓存，是因为你本地起的服务没设强缓存，或 DevTools 勾了 Disable cache。但上线后：微信内置浏览器、钉钉、企业微信、华为 EMUI 内置 WebView 等，会无视 Cache-Control: no-cache，硬把 index.html 存进磁盘缓存几小时甚至几天；用户点开链接，直接从本地读旧 HTML，再加载一堆带旧哈希的 JS，结果就是“明明发版了，用户还是看不到新功能”。
- 强制刷新只影响当前会话，对已安装 PWA、已触发 Service Worker、或被 WebView 预加载的页面无效
- 无痕模式、清除浏览器缓存，是用户侧操作，不能作为线上兜底方案
-
<meta http-equiv="Cache-Control">在所有现代浏览器中均被忽略，写它等于没写
Nginx 必须单独禁用 index.html 缓存
JS/CSS 可以用文件名哈希（如 app.[contenthash:8].js）放心设长缓存，但 index.html 不行——它没哈希，又没版本标识，必须靠响应头强制不缓存。
- 在 Nginx 的
location = /index.html块里加这三行，缺一不可： add_header Cache-Control "no-cache, no-store, must-revalidate";add_header Pragma "no-cache";add_header Expires "0";- 别写
expires -1或max-age=0，部分安卓 WebView 对这些识别不稳定 - 不要把这条规则泛化到
/或/*.html，否则会误杀其他静态 HTML 页面
uni-app 构建时必须让 index.html 也带哈希
光靠响应头还不够。某些定制 ROM（比如 OPPO、vivo 的系统浏览器）会跳过响应头，只认 URL 是否变化。所以 index.html 本身也要哈希化，确保每次构建生成不同路径，例如 index.abc12345.html。
立即学习“前端免费学习笔记（深入）”；
- 在
vue.config.js中配置html-webpack-plugin： configureWebpack: { plugins: [new HtmlWebpackPlugin({ filename: 'index.[contenthash:6].html' })] }- 同时改 Nginx 的
try_files，支持 fallback 到最新哈希文件：try_files $uri $uri/ /index.[hash].html;（实际需用正则或动态 fallback，Nginx 不支持变量 hash，推荐用try_files $uri $uri/ /index.html;+ 响应头兜底） - 若启用了 PWA，
skipWaiting: true和clientsClaim: true必须开启，否则新 Service Worker 卡在 waiting 状态，不会接管页面
最容易被忽略的点：HTML 缓存失效 ≠ JS/CSS 自动更新
即使你做到了上面所有，仍可能出问题：比如某次构建只改了 index.html 模板里的一个文案，但 JS 文件哈希没变，而旧 JS 里还引用着已删除的组件或 API —— 这时候用户加载的是新 HTML + 旧 JS，直接白屏或报错。
- 必须保证 HTML 和所有资源（JS/CSS）的版本严格对齐：要么全哈希，要么全时间戳，不能混用
- 上线后第一件事不是看页面，而是打开 DevTools → Network → 刷一次，确认
index.html状态码是200（不是from disk cache），且 JS/CSS 请求 URL 里的哈希值与本次构建产物一致 - 微信/钉钉离线包平台发布时，务必上传完整静态目录（含哈希化的
index.xxx.html），否则它们会用自己的默认index.html去加载你的 JS，彻底绕过你的缓存控制
