html缓存更新不能依赖meta标签，因其在现代浏览器中被完全忽略；必须通过服务端响应头（如no-cache）、构建时内容哈希（如app.[hash].js）与客户端校验协同实现。
不能靠 HTML 自己控制缓存更新——meta http-equiv 标签在现代浏览器中基本被忽略，且它对 JS/CSS 等外部资源完全无效。真正能实现“按需更新”的，是服务端响应头、构建时内容哈希、客户端校验三者协同的结果。
为什么 Cache-Control: no-cache 对 HTML 有用，但对 JS/CSS 不行
HTML 文件（如 index.html）必须每次请求都校验是否变更，否则用户永远加载不到带新哈希的 app.abc123.js。所以服务端要配：Cache-Control: no-cache, must-revalidate，强制浏览器发 If-None-Match 或 If-Modified-Since 请求验证。
而 JS/CSS 等静态资源恰恰相反：需要长期缓存（max-age=31536000），但前提是 URL 必须含内容哈希（如 main.f8e2d1.js）。一旦文件内容变，哈希就变，URL 就是全新的——浏览器自然不会复用旧缓存。
- 错误做法：给 JS 加
?v=20261010时间戳参数 → CDN 可能不缓存或缓存失效，且无法保证内容一致性 - 正确做法：Webpack/Vite 构建时启用
contenthash，输出app.[contenthash:8].js - 关键点：
immutable响应头必须加在 JS/CSS 上，告诉浏览器“这个 URL 永远不变”，避免二次验证开销
index.html 被强缓存后，新 JS 永远加载不上
这是最常踩的坑：你改了 JS，构建出 app.def456.js，也部署上去了，但用户打开页面仍加载 app.abc123.js，报错或功能缺失。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
原因只有一个：index.html 被强缓存了（比如 Cache-Control: public, max-age=31536000），浏览器压根没去服务器拉新 HTML，自然看不到新的 script src。
- 现象：Network 面板里
index.html显示200 (from memory cache) - 验证方法：curl -I https://yoursite.com/index.html，看返回头有没有
Cache-Control的长缓存指令 - 修复动作：Nginx 中为
.html文件显式设置短缓存或禁用强缓存，例如：add_header Cache-Control "no-cache, must-revalidate"
Service Worker 场景下，index.html 必须显式缓存
如果你用 Service Worker 实现离线能力，index.html 不进 caches.addAll() 列表，就会导致离线白屏——不是报错，而是连 HTML 都拿不出来。
更隐蔽的问题是缓存名复用：始终用 caches.open('static-v1')，会导致新旧版本资源混存。下次更新后，SW 可能返回旧版 HTML + 新版 JS，模块路径对不上直接报 Cannot find module。
- 每次部署必须变更缓存名，如从
static-v1→static-v2 -
install事件中只开新缓存，activate事件中调用caches.delete('static-v1') - fetch 事件里，对
document请求必须兜底返回已缓存的 HTML，不能 fallback 到网络（否则离线失败） -
/version.json这类校验端点，响应头必须加Cache-Control: no-cache, must-revalidate，且前端 fetch 时设cache: 'no-store'
真正的“按需更新”不是靠改个 meta 或加个时间戳就能成的——它依赖构建产物的 URL 稳定性、服务端缓存策略的精确分层、以及客户端（尤其是 SW）对缓存生命周期的主动管理。漏掉任意一环，用户看到的就还是旧世界。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
