HTML缓存验证必须用HTTP响应头，meta标签在现代浏览器中完全无效；Cache-Control: no-cache要求每次使用前发起条件请求并验证，配合ETag或Last-Modified实现304协商缓存。
HTML缓存验证标记必须用响应头，meta标签完全无效
浏览器对 HTML 的缓存行为只认 HTTP 响应头，<meta http-equiv="Cache-Control"> 在现代 Chrome、Firefox、Edge 中被彻底忽略——它只在某些老旧 WebView 或 IE 兼容模式下“可能起效”，但绝不可依赖。真实生效的只有服务端返回的 Cache-Control、ETag、Last-Modified 这三类响应头。
常见错误是写完 <meta> 就以为 HTML 不会缓存了，结果上线后用户刷新半天还是旧页面，排查半天才发现 DevTools Network 里根本没看到对应响应头。
Cache-Control: no-cache 是验证前提，不是禁止缓存
no-cache 的语义常被误解：它不阻止浏览器存 HTML，而是强制每次使用前发起条件请求（带 If-None-Match 或 If-Modified-Since）。服务器收到后比对 ETag 或修改时间，未变则返回 304 Not Modified，浏览器复用本地副本。
-
no-cache, must-revalidate, max-age=0比单纯no-cache更稳妥，明确要求验证且禁用启发式缓存 - 不要混用
public或max-age——比如public, max-age=3600会让 CDN 缓存一小时，用户改完 HTML 立刻发布，CDN 还在吐旧文件 - Nginx 配置中
expires epoch等价于Expires: Thu, 01 Jan 1970 00:00:01 GMT，是强制过期的兜底写法，建议和Cache-Control同时设置
验证标记是否生效：只看 Network 面板里的 Response Headers
别信地址栏回车或 F5 刷新——它们可能走内存缓存或强制校验，干扰判断。正确验证步骤：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 打开 Chrome DevTools → Network 标签页 → 勾选 “Disable cache”（临时关闭浏览器本地缓存，排除干扰）
- 硬刷新（
Ctrl+Shift+R）确保发起完整请求 - 找到
index.html（或对应 HTML 路径）请求 → 点开 → 切到 Headers 标签 → 查看 Response Headers 区域 - 确认存在：
Cache-Control: no-cache, must-revalidate, max-age=0和Expires: Thu, 01 Jan 1970 00:00:01 GMT - 再看 Status 列：
304 Not Modified表示协商验证成功；200 OK且 Size 显示具体字节数，说明没走缓存或验证失败
额外注意：x-cache（Cloudflare）或 x-cdn-cache（阿里云）这类响应头若显示 HIT，而你的源站已返回 no-cache，说明 CDN 层覆盖了配置——必须去 CDN 控制台把 HTML 路径设为“绕过缓存”或 TTL=60s，不能依赖默认策略。
ETag 和 Last-Modified 二选一，优先用 ETag
ETag 是资源内容的哈希指纹，只要 HTML 文件内容有变，ETag 就变，验证精度高；Last-Modified 只精确到秒，且依赖服务器文件系统时间，容易因部署脚本 touch 时间戳导致误判。
- Nginx 中可通过
add_header ETag ""让模块自动生成（需启用etag on） - 如果后端是 Node.js（如 Express），直接
res.set('ETag', crypto.createHash('md5').update(htmlContent).digest('hex'))更可控 - 不要同时禁用两者又不提供替代验证机制——否则
no-cache下浏览器仍会发请求，但服务器无法比对，只能返回完整 200，失去协商意义
真正容易被忽略的是 CDN 和源站响应头的一致性：哪怕 Nginx 配置完美，CDN 后台单独给 /index.html 设置了 10 分钟缓存，用户看到的就是 CDN 缓存的旧 HTML，连刷新都不管用。
