<meta http-equiv="Cache-Control"> 在现代浏览器中完全无效，因Chrome 124+、Firefox 125+、Safari 17+已移除对其解析逻辑，缓存决策仅由服务器返回的HTTP响应头（如Cache-Control）决定，Network面板中绝不会显示meta注入的缓存头。
Meta 标签的 http-equiv 对浏览器缓存策略基本无效，现代浏览器（Chrome 124+、Firefox 125+、Safari 17+）完全忽略 Cache-Control、Expires、Pragma 等缓存相关声明。
为什么 http-equiv="Cache-Control" 在 Network 面板里看不到效果
你在 DevTools 的 Network → Response Headers 里永远找不到由 <meta http-equiv="Cache-Control"> 注入的缓存头——因为浏览器压根不解析它。HTTP 缓存决策只看服务器实际返回的响应头，http-equiv 不参与任何缓存流程。即使你写了：
<meta http-equiv="Cache-Control" content="no-store"> <meta http-equiv="Expires" content="0">
只要服务器返回了 Cache-Control: public, max-age=3600，浏览器就按这个执行。本地用 file:// 打开时连 HTTP 头都没有，meta 更是彻底失效，但这常被误当作“它本来能工作”。
哪些 http-equiv 值至今仍被浏览器支持
不是所有 http-equiv 都废了，但和缓存无关的几个还在起作用：
立即学习“前端免费学习笔记（深入）”；
-
http-equiv="Content-Type"：仍被广泛支持，用于声明字符集，如content="text/html; charset=utf-8" -
http-equiv="Refresh"：可触发页面跳转或重载，例如content="3;url=thank-you.html"，但注意它不绕过缓存，目标页是否更新仍取决于其自身响应头 -
http-equiv="Content-Security-Policy"：现代浏览器支持，用于设置 CSP 策略（注意：必须放在<head>最前面，否则可能被忽略） -
http-equiv="X-UA-Compatible"：仅 IE 有效，已无实际意义
而 Cache-Control、Expires、Pragma 这三类，在 Chrome/Firefox/Safari 中均被明确移除解析逻辑，W3C 也未要求实现。
当服务端无法配置响应头时，前端唯一可行的补救手段
比如托管在 GitHub Pages、Netlify 或纯静态 CDN 上，没有权限改服务器头，此时只能靠 URL 层面扰动来规避缓存：
- 跳转时加时间戳参数：
window.location.href = "page.html?t=" + Date.now()，比Math.random()更可靠 - 避免用
location.replace()：它不产生历史记录，但缓存行为与href完全一致 - 对关键资源（如 JS/CSS）做哈希命名后，HTML 文件本身必须禁用强缓存——这仍需服务端设
Cache-Control: no-cache，前端无法替代
写一堆 meta 标签只会掩盖问题：你以为加了就安全了，结果用户刷新还是看到旧 HTML，引用的却是新构建的 main.abc123.js，导致白屏或报错。
验证缓存是否生效的唯一正确方式
别信 F5 或地址栏回车——它们可能走内存缓存或强制校验。必须：
- 打开 DevTools → Network → 刷新页面
- 找到
index.html请求 → 看 Response Headers 里是否有Cache-Control字段，且值符合预期（如no-cache） - 再看 Status：是
304 Not Modified（协商缓存生效），还是200 OK（未缓存），或是200 from disk cache（强缓存命中）
真正容易被忽略的是：HTML 缓存策略和 JS/CSS 必须分开设计——HTML 要短生命周期（no-cache），JS/CSS 可长周期（max-age=31536000 + 内容哈希）。混用或依赖 meta 统一控制，必然出问题。
