HTML本身不能设置缓存策略
HTML文件只是资源，不是缓存控制的执行方。真正起作用的是HTTP响应头，比如 Cache-Control、Expires。浏览器在收到HTML响应时，根据这些头字段决定是否缓存、缓存多久、是否需要校验。把缓存逻辑写进HTML标签（比如<meta http-equiv="Cache-Control">）基本无效——现代浏览器完全忽略这类meta声明。
常见错误现象：
– 页面改了但用户还在用旧HTML
– 刷新后CSS/JS没更新，布局错乱
– 本地开发用file://协议测试，误以为meta生效了（其实连HTTP头都没有）
必须通过服务器配置HTTP缓存头
不同部署环境配置方式不同，核心是让服务器对HTML响应返回正确的Cache-Control值：
- Nginx：在location块里加
add_header Cache-Control "no-cache, no-store, must-revalidate";（适合HTML这类常变文件） - Apache：用
Header set Cache-Control "public, max-age=3600"配合.htaccess或虚拟主机配置 - Node.js（Express）：用
res.set("Cache-Control", "no-cache")在路由中显式设置 - 静态托管服务（如Vercel、Netlify）：靠
_headers文件或netlify.toml规则，例如匹配/**/*.html并设cache-control: public, max-age=0, must-revalidate
关键点：
– HTML通常应禁用强缓存（max-age=0或no-cache），避免用户卡在旧版本
– 但no-store会禁止所有缓存（含内存缓存），影响首屏性能，一般不需要
– 不要给HTML设长缓存（如max-age=31536000），那是给指纹化命名的JS/CSS用的
立即学习“前端免费学习笔记（深入）”；
HTML里的<meta http-equiv>为什么不管用
这个标签设计初衷是模拟HTTP头，但实际支持度极差：
- Chrome、Firefox、Safari均不解析
<meta http-equiv="Cache-Control">用于缓存决策 - 只有极老版本IE部分支持，且行为不一致
- 它不影响HTTP请求流程，也不触发重新验证（ETag/Last-Modified校验）
- 如果真写了，反而可能误导开发者以为“已控制缓存”，掩盖真实配置缺失
使用场景仅剩一种：SEO工具或离线文档生成器需要在无服务器环境下输出自解释的HTML，但此时缓存本就不可控，写也没意义。
如何验证HTML缓存是否生效
别信F5刷新或地址栏回车——它们可能走内存缓存或强制校验。正确验证方式：
- 打开DevTools → Network → 刷新页面 → 找到HTML请求 → 看Headers面板里的
Response Headers是否含Cache-Control或Expires - 检查Status列：如果是
200 OK（非304 Not Modified或200 from memory cache），说明没走缓存；如果是304，说明协商缓存生效；如果是200 from disk cache，说明强缓存生效（对HTML来说这通常是错的） - 用curl命令验证原始响应：
curl -I https://yoursite.com/index.html，直接看返回头
容易被忽略的一点：CDN节点可能覆盖源站头。即使你服务器配对了，CDN后台若单独设置了HTML缓存规则，最终生效的还是CDN的值。得去CDN控制台查或联系配置人。
