HTML请求是否走缓存，直接看Network面板Size列：显示“from memory cache”或“from disk cache”表示命中强缓存；显示具体字节数且状态码为200表示重新下载；状态码为304表示协商缓存生效。
怎么看 Network 面板里 HTML 请求是否走缓存
直接看 Size 列：如果是 from memory cache 或 from disk cache，说明浏览器用了本地缓存；如果是具体字节数（如 12.4 KB）且状态码是 200，代表重新下载；若状态码是 304，说明走了协商缓存——服务器确认没变，复用本地副本。
注意两个常见误判：
-
200 OK (from memory cache)看似正常，但可能掩盖了Cache-Control: no-cache导致的强制验证——它每次都要发请求，只是服务器快速回了 304 -
200 OK+ 小体积（比如287 B）不等于“没缓存”，可能是服务端返回了精简版 HTML（如 SSR fallback），和你本地缓存的完整版根本不是一回事
为什么明明设了 Cache-Control: public, max-age=3600 却还是发请求
因为浏览器只认响应头，不认 。这个 meta 标签在 Chrome、Firefox、Edge 中完全被忽略，仅旧版 Safari 可能降级识别——线上环境别依赖它。
真正生效的方式只有服务器响应头。排查路径：
- 用
curl -I https://yoursite.com/index.html看返回头里有没有Cache-Control - Nginx 配置中检查是否写在
location = /index.html块里，而不是笼统地套在location ~ \.html$下（后者可能被更具体的规则覆盖） - CDN 或反向代理（如 Cloudflare、Nginx proxy_pass）可能覆盖或清空了原始响应头，需单独配置其缓存策略
max-age 和 must-revalidate 组合的实际效果
Cache-Control: public, max-age=3600, must-revalidate 不是“缓存 1 小时后自动刷新”，而是：1 小时内直接用缓存；超时后，必须发起一次验证请求（带 If-None-Match 或 If-Modified-Since），等服务器明确说“没变”（304）才能继续用——哪怕网络断了，也不许用过期缓存。
这对 HTML 很危险：
- 用户打开页面时刚好超时，而你的服务器或 CDN 返回了 5xx，浏览器就只能显示空白或错误页
- 如果服务端没配
ETag或Last-Modified，must-revalidate实际退化成no-cache，每次都是 304 或 200 - 动态页（如带用户信息的 dashboard）不该用
public，否则 CDN 可能把张三的首页缓存下来，再返回给李四
怎么确认 HTML 缓存是否影响 JS/CSS 更新
HTML 缓存时间越长，对 JS/CSS 路径的容错要求越高——因为浏览器只缓存 HTML 文件本身，不缓存它里面写的 <script src="main.js"></script> 的内容。一旦 HTML 缓存没失效，而你又没给 main.js 加内容哈希（如 main.a1b2c3.js），用户就会加载旧 HTML + 旧 JS，白屏或逻辑错乱。
验证方法：
- 改一行 JS 逻辑，构建后部署，然后硬刷页面（
Cmd+Shift+R）；如果功能没变，说明 HTML 拿的是旧缓存，且 JS 路径没变 - 在 Network 面板过滤
main.js，看它的响应头是否有Cache-Control: public, max-age=31536000, immutable——没有的话，光 HTML 缓存再久也没用 - 检查构建产物：Webpack 要开
contenthash，Vite 默认行为已满足；若用html-webpack-plugin，确保filename是index.html，而非带 hash 的名字（否则缓存失效）
关键点在于：HTML 缓存不是独立优化项，它和资源路径稳定性、服务端响应头、CDN 行为绑死。一个环节松动，整个链路就失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
