html缓存不保证实时性，需主动干预：no-cache强制协商验证，max-age=3600等强缓存跳过请求；静态资源宜长缓存配哈希，html应设no-cache或max-age=0,must-revalidate；meta标签无效，仅响应头生效。
HTML缓存机制本身不保证实时性——它默认倾向「快」而非「新」。要让缓存和实时性共存，得靠主动干预策略，而不是依赖默认行为。
Cache-Control 的 max-age 和 no-cache 本质区别
很多人以为 no-cache 是“不缓存”，其实它只是强制每次请求都走协商缓存流程：浏览器仍可存资源，但必须先发 If-None-Match 或 If-Modified-Since 头给服务端验证。服务端返回 304 Not Modified 就用本地副本，否则返回新内容。
max-age=3600 这类强缓存则完全跳过网络请求，哪怕服务端数据已变，浏览器也照用一小时。所以实时性差的根源常在这里。
- 静态资源（JS/CSS/图片）适合设较长
max-age，配合文件哈希命名实现自动更新 - HTML 文件本身建议设
no-cache或max-age=0, must-revalidate，避免整页缓存导致用户看不到最新结构 - 若用 CDN，需确认其是否尊重源站的
Cache-Control头，有些 CDN 会覆盖或截断
ETag 和 Last-Modified 怎么配合用才不翻车
ETag 是服务端生成的资源指纹（如文件内容 MD5），Last-Modified 是时间戳。两者都用于协商缓存，但行为有差异：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
Last-Modified精度只到秒，同一秒内多次更新可能被忽略；且时钟不同步时易出错 -
ETag更精准，但服务端计算成本略高；若用弱校验（W/"xxx"），内容语义等价即认为未变（比如空格增减） - 不要同时禁用两者又不提供替代机制——某些老旧代理会忽略
ETag，只认Last-Modified - 动态 HTML（含用户态）应禁用
Last-Modified，因时间戳无法反映个性化逻辑变化
Service Worker + Cache API 怎么做“新鲜优先”
纯 HTTP 缓存控制粒度粗，真正需要实时性的页面（如仪表盘、消息列表），得靠 Service Worker 手动调度。核心是绕过浏览器默认缓存决策，自己决定何时用缓存、何时拉新。
- 用
caches.match()先查缓存，命中就渲染；再立即发fetch()请求新数据，成功后更新缓存并触发 UI 刷新（如通过postMessage） - 对关键接口，可在
fetch时加cache: 'no-store'强制跳过所有缓存，确保取到最新响应 - 避免在
install阶段用cache.addAll()缓存 HTML——这会导致离线时永远显示旧版页面结构 - 更新 Service Worker 脚本后，旧缓存不会自动清，需在
activate事件里调用caches.delete()清理旧 cacheName
HTML Meta 标签为什么基本没用
<meta http-equiv="Cache-Control" content="no-cache"> 这类写法在现代浏览器中已被忽略，仅对极少数不支持 HTTP 头的古老环境有效。W3C 明确指出：这类 meta 标签不适用于 HTTP 缓存控制。
真实生效的只有响应头里的 Cache-Control、Expires、ETag 等。如果你在 Nginx 或后端框架（如 Express、Django）里没配响应头，单靠 HTML 里的 meta 标签，等于没设缓存策略。
最容易被忽略的一点：HTML 页面自身往往是最该被「禁止强缓存」的资源，但它恰恰最容易被误配成 max-age=31536000 ——结果用户刷新半天还是旧版 DOM，连 JS 逻辑都跑不起来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
