meta标签对现代浏览器缓存控制基本无效，真正起效的是服务器返回的HTTP响应头；仅在file://协议、老旧WebView等极少数边缘场景下可能被部分解析，且不影响JS/CSS等资源。
meta 标签对现代浏览器的缓存控制基本无效，不能依赖它来可靠禁用缓存。
真正起作用的是服务器返回的 HTTP 响应头。但如果你必须用 meta（比如静态托管、无法改服务端配置），得知道它只在极有限场景下“可能”被部分浏览器读取，且仅影响 HTML 文档本身——JS/CSS/API 完全不受影响。
为什么 meta http-equiv 在现代浏览器中大多失效
浏览器优先遵循 HTTP 响应头中的 Cache-Control、Expires 等字段，meta 标签属于降级兼容方案，Chrome、Firefox、Safari 等主流浏览器自 2010 年代后期起已明确忽略这类声明（尤其在前进/后退、刷新、iframe 加载等路径下）。
即使你写了：
<meta http-equiv="Cache-Control" content="no-store"> <meta http-equiv="Pragma" content="no-cache"> <meta http-equiv="Expires" content="0">
只要服务器返回了 Cache-Control: public, max-age=3600，浏览器就按服务端头执行，完全无视 meta。
- HTTP 头的优先级永远高于
meta -
meta只在页面首次加载时被解析，后续导航（如location.href跳转）不重新触发解析 - CDN、代理、中间网关根本看不到
meta，它们只看响应头
哪些场景下 meta 标签还“有点用”
仅限以下几种边缘情况：
立即学习“前端免费学习笔记（深入）”；
- 纯本地文件打开（
file://协议），无 HTTP 服务，此时浏览器无响应头可读，会尝试 fallback 到meta - 某些老旧内嵌 WebView（如旧版 Android System WebView 或 Electron 低版本）尚未完全移除该逻辑
- 用户手动“另存为”HTML 后双击打开，且未经过任何服务器
这些都不是生产环境常见路径。如果你正在调试 SPA 首屏白屏或样式错乱，别花时间调 meta，直接查 Network 面板里 index.html 的响应头是否为 no-store。
如果非要用 meta，怎么写才最接近“尽力而为”
把能塞的指令都塞进去，不求生效，只求覆盖尽可能多的历史兼容性组合：
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0"> <meta http-equiv="Pragma" content="no-cache"> <meta http-equiv="Expires" content="Tue, 01 Jan 1980 1:00:00 GMT">
注意点：
- 必须放在
内，且越靠前越好（避免被 JS 动态插入干扰） -
no-store比no-cache更严格，前者禁止存储任何副本，后者允许存但强制验证 -
Expires设为过去时间比设0更稳妥，部分旧代理对0解析不一致 - 即便这样写，也不能阻止
app.js?v=1.2被缓存——静态资源缓存由各自请求的响应头决定，和 HTML 的meta无关
真正该做的：改服务器响应头，不是改 HTML
所有靠谱的缓存控制，都发生在服务端：
- Nginx：在
location = /index.html块里加add_header Cache-Control "no-store"; - Apache：
.htaccess中加Header set Cache-Control "no-store"（需启用mod_headers） - Node.js（Express）：
res.set("Cache-Control", "no-store")在对应路由中 - 静态托管平台（Vercel/Netlify/GitHub Pages）：通过
_headers或vercel.json显式配置
如果你连服务端都没法动，那就用“破缓存”手段：给 HTML 请求加随机查询参数，比如 index.html?t=1746071040，每次构建或部署时更新。这不是禁用缓存，而是让浏览器认为这是个新 URL —— 这比死磕 meta 实在得多。
meta 缓存控制就像给汽车贴“请勿启动”标签却不拔钥匙——看起来认真，但真正决定能不能跑的，是引擎和电路系统。 
