html模板更新后仍显示旧内容的根源是多层缓存叠加：service worker、http cache及cdn强缓存共同导致url不变时资源不更新；需按序清除cache storage、service worker和http cache，并通过构建哈希或etag实现可预测缓存失效。
HTML模板更新后仍显示旧内容，不是缓存没清，而是没清对地方
直接 Ctrl+F5 或清 Cookies 根本无效——旧模板“复活”的真正原因，是多层缓存叠加：Service Worker 从 Cache Storage 返回预存的 index.html，而服务器又返回了 Cache-Control: public, max-age=3600，浏览器连请求都不发。你改了模板文件，但 URL 没变，所有缓存层都认它是“同一个资源”。
必须按顺序击穿三层：
- 先关掉 DevTools 里的
Disable cache（它只临时绕过，关掉就失效） - 再进
chrome://settings/siteData→ 搜索域名 → 点“移除”，确保Cache Storage、Service Worker、HTTP Cache全清空 - 最后检查 Nginx 或 CDN 是否对
*.html做了强缓存（比如 Cloudflare 的 Page Rule），临时加响应头Cache-Control: no-store验证
用 localStorage 存模板字符串？小心 XSS 和大小限制
有人把渲染后的 HTML 片段存进 localStorage.setItem('tpl-home', htmlStr)，看似省请求，实则埋雷：
-
localStorage容量通常只有 5MB，但单个模板字符串若含 base64 图片或内联样式，很容易超限，触发QuotaExceededError - 若模板含用户输入内容（如评论区 HTML），直接
innerHTML = localStorage.getItem('tpl-home')会执行任意脚本，XSS 风险极高 -
localStorage是同步 API，大模板读写会阻塞主线程，滚动或交互时明显卡顿
更稳妥的做法是：只存轻量元数据（如版本号、时间戳），用 fetch() 加载模板，再用 DOMParser 安全解析：new DOMParser().parseFromString(htmlStr, 'text/html')。
Service Worker + Cache API 实现组件级模板缓存
想让某个组件模板（如 header.html）独立缓存、独立更新，别碰已废弃的 appcache.manifest，直接用 Cache API 配合 fetch 事件拦截：
- 在
sw.js的install阶段，用caches.open('tpl-v1').then(cache => cache.addAll(['/header.html', '/footer.html']))预缓存 - 在
fetch事件里，对匹配/\.(html|htm)$/.test(req.url)的请求，优先查caches.match(req)，未命中才fetch(req) - 更新模板时，不要改文件名，而是升级缓存名（如从
tpl-v1改为tpl-v2），并在activate阶段调用caches.delete('tpl-v1')
注意：HTML 文件必须带正确 MIME 类型 text/html，否则 caches.match() 可能不命中；且 Cache API 不支持通配符，/components/*.html 这种写法无效，得列全路径。
构建时注入哈希值，比 runtime 缓存更可靠
依赖客户端缓存永远有不确定性。最稳的方式，是在构建阶段就把模板版本“焊死”在 URL 里：
- Webpack/Vite 打包时，给 HTML 模板文件生成 content hash，输出成
header.7a2f3b.html - 在 JS 中动态加载：
fetch('/header.7a2f3b.html')，URL 变了，浏览器必然走新请求 - 如果模板由后端吐出（如 SSR），就在响应头加
ETag: "header-7a2f3b"，配合If-None-Match协商缓存
这个思路的本质不是“怎么缓存”，而是“怎么让缓存失效变得可预测”——所有缓存机制都建立在 URL 不变的前提下，一旦 URL 变，旧缓存自然作废，连 Service Worker 都不用手动清理。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
