直接看Network面板的Size列和状态码即可判断HTML缓存状态：显示“from memory cache”或“from disk cache”为强缓存命中；Size为具体字节数且状态码200为未命中；状态码304为协商缓存生效。
直接看 Network 面板的 Size 列和状态码，就能判断 HTML 是否被缓存、走的是强缓存还是协商缓存。
怎么看 HTML 请求是否命中缓存
打开 DevTools → Network → 刷新页面 → 找到 index.html（或你实际的 HTML 文件名）那一行：
- 如果
Size显示from memory cache或from disk cache：说明强缓存生效，浏览器根本没发请求 - 如果
Size是具体字节数（比如2.4 KB），且状态码是200：说明缓存失效，服务器返回了完整响应体 - 如果状态码是
304 Not Modified：说明协商缓存生效，浏览器发了带If-None-Match或If-Modified-Since的请求，服务端确认没变，只回了头
注意：Ctrl+Shift+R（硬刷）会跳过所有缓存，永远触发 200；普通回车或 F5 才走真实缓存逻辑。
为什么 meta http-equiv="Cache-Control" 没用
现代浏览器（Chrome/Firefox/Safari/Edge）完全忽略 HTML 里的 <meta http-equiv="Cache-Control" content="...">。这不是 bug，是规范行为 —— HTTP 缓存策略必须由服务端通过响应头决定。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 你在
index.html里加这行，DevTools 的 Response Headers 里根本不会出现Cache-Control - 真正起作用的只有服务端返回的响应头，比如 Nginx 的
add_header Cache-Control "public, max-age=300"，或 Express 的res.set('Cache-Control', 'no-cache') - 这个误区特别容易在本地双击打开
file://协议时强化——此时根本没有响应头，缓存行为不可控，务必用本地服务器（如npx serve）测试
怎么确认 ETag 或 Last-Modified 是否生效
协商缓存要生效，得同时满足两个条件：强缓存已过期 + 服务端正确返回了校验字段。
- 先检查响应头里有没有
ETag或Last-Modified；没有就不可能触发协商 - 再看后续请求的请求头里有没有带上
If-None-Match（对应 ETag）或If-Modified-Since（对应 Last-Modified）；没有说明浏览器压根没尝试校验 - 常见坑：
Cache-Control: max-age=31536000太长，导致一年内都走强缓存，ETag根本没机会出场 - 调试时可临时把
max-age改成5秒，再刷新两次，就能稳定复现200 → 304流程
SPA 场景下 index.html 缓存最容易出问题
单页应用中，index.html 是入口，但 JS/CSS 文件通常带哈希（如 main.a1b2c3.js）。如果 index.html 被强缓存太久，用户本地还拿着旧 HTML，就会去加载旧版哈希文件（已 404），结果白屏或功能异常。
- 正确做法：
index.html必须短缓存，例如Cache-Control: public, max-age=300（5 分钟）或no-cache -
no-cache不代表“不缓存”，而是强制每次发起协商请求（带If-None-Match），只要服务端配置了ETag，依然能高效复用 - 别信“HTML 不大，缓存久点没关系”——错配比体积重要得多
真正难的不是看懂面板，而是理解哪一层缓存正在起作用；一旦混淆强缓存和协商缓存的触发时机，排查就会陷入死循环。
