HTML模板不能分块放进离线包，因其作为页面入口和逻辑锚点必须保持原子性；分块会导致DOM错乱、版本不一致、校验失败及缓存失效，应采用network-first策略配合响应头或meta标签进行全局版本校验。
HTML 模板不该分块放进离线包——它不是静态资源，分块对比只会让版本校验失效、回滚失控。
为什么 HTML 模板不能像 JS/CSS 那样做分块哈希比对
HTML 是页面入口和逻辑锚点，一旦被切分成块（比如 header、main、footer 三个 template 片段），就破坏了它的原子性。离线包更新时若只替换其中一块，而其他块仍缓存旧版，会导致 DOM 结构错乱、querySelector 失败、JS 初始化报错。
- 分块后无法保证 HTML 全局版本一致性：你发了 v2.1 的
main模板，但用户本地还挂着 v2.0 的header，data-version属性不匹配，JS 校验直接中断 - Service Worker 的
caches.open()操作面向完整响应体，不是 DOM 节点；你没法对一个<template id="sidebar">单独缓存或更新 - 构建工具（如 Vite、Webpack）生成的 content-hash 只作用于输出文件，不适用于运行时拼接的模板片段——
import.meta.env.BASE_URL或fetch('/templates/sidebar.html')返回的仍是未 hash 的路径，无法触发精准缓存命中
HTML 模板必须走 network-first，且带可验证指纹
真正可控的做法是：HTML 模板文件（哪怕拆成多个 .html 片段）全部通过网络请求加载，并在响应头或 <meta> 中注入版本标识，由 Service Worker 主动校验。
- 后端返回时加
X-Template-Version: 2a7f3e响应头，SW 在fetch事件中读取并比对预设的CURRENT_TEMPLATE_VERSION - 或在模板文件
<head>内写<meta name="template-hash" content="sha256:8d4a9c...">，用DOMParser解析后校验（注意：只解析一次，缓存结果，避免重复开销） - 校验失败不阻塞渲染，但触发
updateOfflineBundle()—— 这个函数应下载整套新模板 + 对应的 JS/CSS 离线包，而非只更新某一块 - 路径必须精确：若模板请求是
/templates/dashboard.html?ts=1719771540，SW 缓存 key 就得是这个完整 URL；加 query 参数是为了绕过 CDN 缓存，但也要确保 SW 中cache.match()能匹配上
离线包里只放真正静态的模板依赖项
能放进离线包的，只有那些与 HTML 模板解耦、自身带 content-hash、且不参与逻辑分支判断的资源。
立即学习“前端免费学习笔记（深入）”；
-
icons/下的 SVG 雪碧图（文件名含 hash，如icon-menu-9f3a2b.svg） -
locales/下的 JSON 语言包（构建时生成zh-CN-8e2d1f.json，HTML 模板里通过data-i18n-key引用） -
components/中纯声明式的 Web Component 定义（如my-card.js，已用 rollup 打包并 hash） - 绝对不要放
templates/目录本身——哪怕你给每个模板文件都加了 hash，只要 HTML 里引用的是dashboard.html而不是dashboard-5c8d2a.html，SW 就无法区分版本
最常被忽略的一点：HTML 模板的“热更新”本质不是文件级替换，而是版本号驱动的状态切换。你改了一个 <button class="primary"> 为 <button class="cta">，真正起作用的不是 diff 工具算出的那几行变更，而是整个模板文件的 hash 变了，从而触发 SW 清理旧缓存、拉取新包、重载页面——这个过程不能被“局部更新”妥协。
