如何理解HTML缓存机制中的强缓存原理-html教程-PHP中文网

强缓存是否生效只取决于响应头中Cache-Control指令是否存在且未过期，与HTML是否为入口文件或内容是否变化无关；命中时浏览器不发任何请求，DevTools显示200(from memory/disk cache)。

如何理解html缓存机制中的强缓存原理

强缓存不发请求，只看响应头里的 `Cache-Control`

浏览器对 HTML 文件是否走强缓存，根本不管它是不是“页面入口”，也不看文件内容有没有变——只严格检查服务器返回的响应头中是否存在有效的 Cache-Control 指令，且未过期。一旦命中，连 TCP 连接都不会建立，DevTools Network 面板里显示 200 (from memory cache) 或 200 (from disk cache)，状态码是 200，但没有真实 HTTP 交互。

常见误区是以为 HTML 不能强缓存，或者必须配 no-cache 才安全。其实只要服务端返回了 Cache-Control: public, max-age=300，浏览器就会在 5 分钟内完全跳过请求，哪怕你点的是书签、地址栏回车、甚至 JS 跳转过去，都一样生效。

max-age 是相对时间（秒），从响应被接收那一刻开始倒计时，不受客户端时间偏差影响
Expires 在现代浏览器中基本被忽略，即使写了也压不过 Cache-Control
public 和 private 对 HTML 影响不大，除非你用 CDN 或反向代理，否则默认行为已足够

`no-cache` 不等于“不缓存”，而是强制走协商流程

很多人把 no-cache 当作“禁止缓存 HTML”，结果发现页面还是没更新——因为 no-cache 其实允许浏览器存下 HTML，只是每次访问都必须带上 If-None-Match 或 If-Modified-Since 去和服务端确认。如果服务端返回 304 Not Modified，浏览器就继续用磁盘/内存里那个旧 HTML。

这意味着：HTML 文件本身还在缓存里，只是没被“直接复用”。如果你的服务端没正确返回 ETag 或 Last-Modified，或者构建流程导致这些值长期不变，no-cache 就会变成“永远 304”，用户卡在旧版本里出不来。

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

用 no-cache 前，确保 Nginx / Apache / Node.js 服务端实际生成并返回了可靠的 ETag
静态托管平台（如 Vercel、Netlify）通常默认开启 ETag，但自建 Nginx 需显式配置 etag on;
若构建产物无哈希、HTML 每次都重写，Last-Modified 可能每秒都变，反而让协商缓存失效

HTML 强缓存最容易踩的三个坑

HTML 是整个页面的入口，它的缓存行为直接影响所有子资源加载逻辑。强缓存配错，不是慢一点，而是整个更新链路断掉。

把 Cache-Control: max-age=31536000 直接套在未哈希的 index.html 上——用户首次加载后，一年内都看不到新版本，连强制刷新（Ctrl+F5）都不行（因为强缓存不触发请求）
误信 <meta http-equiv="Cache-Control" content="no-cache"> 能控制缓存——它在 Chrome/Firefox/Edge 中完全无效，只对极少数直接输入 URL 的场景有微弱影响
开发环境用 webpack-dev-server 或 vite，默认禁用强缓存（返回 Cache-Control: no-cache），但上线后忘了配服务端头，导致生产环境意外启用强缓存