<meta http-equiv="Pragma" content="no-cache">在现代浏览器中完全无效，真正有效的缓存控制必须通过服务端响应头（如Cache-Control: no-store）实现。
meta里的Pragma根本不起作用
直接说结论：<meta http-equiv="Pragma" content="no-cache"> 在 Chrome 124+、Firefox 125+、Safari 17+、Edge 125+ 中完全被忽略。这不是你写错了，是浏览器主动跳过——W3C 规范从未要求支持这种写法，现代引擎连解析都不做。
它只在两种极窄场景下可能“碰巧”生效：HTTP/1.0 客户端（比如某些嵌入式设备）请求时，或服务端同时返回了真实的 Pragma: no-cache 响应头（此时真正起效的仍是 Cache-Control，Pragma 只是冗余字段）。
所以，如果你靠这行 meta 标签来防缓存，页面大概率会白屏或加载旧 JS/CSS —— 因为它对实际资源加载零影响。
真正有效的缓存控制必须走响应头
禁缓存的唯一可靠路径是服务端发正确的 HTTP 响应头，不是 HTML 里塞 meta。Nginx、Apache、PHP 或 Node.js 都得配 Cache-Control，其他字段只是补充：
立即学习“前端免费学习笔记（深入）”；
-
Cache-Control: no-store是最彻底的选项：禁止浏览器和中间代理存任何副本，每次强制重拉 -
Pragma: no-cache和Expires: 0必须由服务端发出才有效，且仅对老旧网关或部分企业 CDN 有意义；漏掉它们，某些中间层可能覆盖你的Cache-Control - 检查 Nginx 配置里有没有全局
expires 1h—— 它会直接覆盖add_header，导致你加的Cache-Control失效
示例 Nginx 片段（放在 location 块内，不是 server 块顶部）：
add_header Cache-Control "no-store"; add_header Pragma "no-cache"; add_header Expires "0";
meta版Cache-Control能用，但有硬限制
如果只能改 HTML（比如静态托管平台不让你配响应头），<meta http-equiv="Cache-Control" content="no-store"> 是唯一还有微弱效果的 meta 方式，但它只管当前 HTML 文档本身：
- 必须放在
<head>最开头，前面不能有空格、BOM 或注释 - 对引入的
script、link、图片等外部资源完全无效 - 用户点「后退」按钮时，仍可能从 bfcache 恢复旧状态——这和 HTTP 缓存无关，meta 和响应头都管不了
- 旧版 IE 要求
cache-control全小写才识别，现代浏览器不敏感，但写成Cache-Control更稳妥
上线前必须验证的三件事
别等用户报白屏才检查：
- 打开 DevTools → Network 面板 → 刷新页面 → 点击
index.html请求 → 看 Response Headers 里有没有Cache-Control: no-store，且状态码是200（不是200 from memory cache） - 手动清一次缓存：Chrome 设置 → 隐私和安全 → 清除浏览数据 → 勾选“缓存的图片和文件”
- 硬刷新测试：用
Ctrl+Shift+R或新开无痕窗口，F5 刷新不可信——它常走内存缓存，误判风险极高
bfcache 是最容易被忽略的环节：哪怕响应头全对，后退仍可能看到陈旧页面。这时要监听 pageshow 事件判断 event.persisted，再决定是否 location.reload()，但会牺牲导航体验，慎用。
