Expires值必须为RFC 7234定义的HTTP-date格式（如Wed, 13 Aug 2026 01:58:00 GMT），禁用本地时间、相对值或非法格式；优先使用Cache-Control，meta标签仅影响HTML自身缓存，不作用于子资源，且易被服务器响应头覆盖。
Expires 的值必须是 HTTP 日期格式，不是相对时间
直接写 2026-08-11 或 3600（秒）会完全失效——浏览器根本不会解析。HTTP 规范要求 http-equiv="expires" 的 content 值必须严格匹配 RFC 7234 定义的 HTTP-date 格式，例如 Wed, 13 Aug 2026 01:58:00 GMT。
常见错误包括：
- 用本地时区时间（如
2026-08-11 01:58:00），缺少时区且格式非法 - 误以为能写相对值（如
content="max-age=3600"），这其实是Cache-Control的语法 - 日期早于当前时间（比如设成昨天），导致资源立即被判定为过期，强制重新请求
优先用 Cache-Control，而不是 Expires
Expires 是 HTTP/1.0 遗留机制，现代浏览器更依赖 Cache-Control。它支持相对时间、更细粒度控制，且不受客户端时间偏差影响（Expires 依赖客户端本地时钟是否准确）。
推荐写法：
立即学习“前端免费学习笔记（深入）”；
<meta http-equiv="cache-control" content="max-age=3600">
等价但更可靠：
-
max-age=3600：资源在客户端缓存 1 小时 -
no-cache：每次使用前必须向服务器验证（非不缓存） -
no-store：禁止任何缓存（含中间代理）
如果必须用 Expires（比如兼容极老系统），请用服务端动态生成合法 HTTP-date 字符串，别硬编码。
meta 标签设置的缓存头仅对 HTML 文档本身生效
<meta http-equiv="expires"> 或 <meta http-equiv="cache-control"> 只影响该 HTML 文件的缓存行为，**不会传递给 JS、CSS、图片等子资源**。这些资源的缓存策略由它们自己的 HTTP 响应头决定（比如服务器返回的 Cache-Control 头）。
所以：
- 改了 HTML 里的
meta，JS 文件照样按自己响应头缓存 - 想统一控制所有静态资源，得配置 Web 服务器（如 Nginx 的
expires指令或add_header Cache-Control） - 开发中常误以为加了 meta 就能“清掉所有缓存”，结果发现 CSS 还是旧的——问题不在 HTML，而在资源本身
调试时注意：meta 缓存指令可能被服务器响应头覆盖
当 HTML 文件由服务器返回时，如果响应头里已有 Cache-Control 或 Expires，浏览器会**优先采用 HTTP 响应头**，忽略 <meta> 设置。这是规范明确规定的。
验证方式：
- 打开浏览器开发者工具 → Network → 找到 HTML 请求 → 查看 Response Headers
- 如果看到
Cache-Control: public, max-age=86400，那<meta>里的设置就不起作用 - 只有响应头里完全没有缓存相关字段时，
<meta>才会生效（极少出现在生产环境）
真正可控的方式永远是服务端输出正确的响应头；<meta> 只适合纯静态文件托管、无后端干预的场景，且可靠性低。
