manifest文件必须用text/cache-manifest mime类型且内容字节级变更才触发更新；cache/network/fallback区段需严格分隔、路径统一；html中manifest属性须为无参数纯路径；application cache已被现代浏览器弃用，应改用service worker。
manifest 文件必须用 text/cache-manifest MIME 类型，且不能靠注释触发更新
浏览器只在 HTTP 响应头明确返回 Content-Type: text/cache-manifest 时才识别 manifest 文件；用 text/plain 或漏配会导致整个缓存机制静默失效。更关键的是，仅修改注释行（如 # v2.1.0）不会触发更新——浏览器只比对 manifest 文件**内容的字节级差异**，空格、换行、注释变动都算数，但多数构建流程会忽略这些“非实质”变更。
常见错误现象：navigator.onLine 为 false 时页面白屏，或资源加载 404，实际是 manifest 被当成普通文本未解析。
- 服务端必须显式配置该 MIME 类型（Nginx：add_type text/cache-manifest .manifest；Apache：AddType text/cache-manifest .manifest）
- 每次发布前确保 manifest 文件内容有真实变更，比如自动注入构建时间戳：
CACHE MANIFEST\n# build: 202606301428 - 避免用
.appcache扩展名——虽被部分旧浏览器支持，但已从 HTML spec 中移除，现代 Chrome/Firefox 完全不识别
CACHE / NETWORK / FALLBACK 区段必须严格分隔，且路径必须相对或绝对一致
清单文件不是自由格式文本，CACHE:、NETWORK:、FALLBACK: 是关键字，冒号后必须换行，且每个区段内路径写法必须统一：要么全用根相对路径（/index.html），要么全用文档相对路径（js/app.js）。混用会导致部分资源被跳过缓存，尤其在子目录 HTML 页面中引用时极易出错。
使用场景：当你的 about.html 在 /pages/about.html，而 manifest 在根目录，那么 CACHE: 里写 js/app.js 实际请求的是 /pages/js/app.js，而非你预期的 /js/app.js。
-
CACHE:下只放确定离线必需的静态资源（HTML、CSS、JS、图标），别塞 API 接口或动态 HTML 模板 -
NETWORK:用*表示“所有未列在 CACHE 或 FALLBACK 的资源都必须联网”，但注意它不匹配已缓存条目——即使/api/user被缓存过，只要没出现在 CACHE 区段，仍走 NETWORK -
FALLBACK:格式必须是online-path offline-path，两个路径之间用空格分隔，不能用制表符或换行
HTML 的 manifest 属性值必须可访问，且不能带查询参数干扰缓存判定
看似简单，但若路径写成 manifest="./cache.manifest" 或 manifest="/v2/cache.manifest"，在某些部署环境下会因 base URL 解析偏差导致 manifest 加载失败。更隐蔽的问题是加了版本参数，比如 cache.manifest?v=2.3.0 —— 浏览器会把它当作全新文件，但下次更新时若只改参数不改内容，依然不会触发更新检测。
性能影响：manifest 文件本身不参与缓存策略，每次 HTML 加载都会重新请求并解析它；若它响应慢或 404，整个离线流程卡在 CHECKING 状态，用户看到白屏或旧版界面。
- manifest 属性值必须是**无协议、无查询参数的纯路径**，推荐
manifest="cache.manifest"并确保该文件与 HTML 同域、同源、可公开访问 - 不要在 HTML 中动态设置 manifest 属性（如 JS 注入），
的 manifest 属性只在首次解析时读取一次，后续 JS 修改无效 - 本地双击打开 HTML 文件时，manifest 机制完全不工作（file:// 协议限制），调试务必用本地服务器（如
npx serve）
Service Worker 已取代 Application Cache，但 manifest 配置仍影响 fallback 行为
Application Cache（即 ）在 Chrome 94+、Firefox 84+ 中已被彻底禁用，但 Safari 16.4 之前仍部分支持；如果你的应用还需兼容老 iOS 设备，manifest 配置不能丢，但它已不再是主缓存机制。真正起作用的是 Service Worker，而 manifest 中的 FALLBACK: 条目，在 SW 环境下**完全不生效**——fallback 逻辑需在 fetch 事件中手动实现。
容易踩的坑：开发者以为写了 FALLBACK: / /offline.html 就能兜底，结果在 SW 控制下，404 请求照样抛出，页面崩溃。SW 的缓存和 fallback 必须自己编码控制，无法继承 manifest 声明。
- 新项目直接放弃
，改用 SW +caches.match()+fetch()fallback 逻辑 - 遗留项目若保留 manifest，仅用于极老设备兜底，
FALLBACK条目仍要写，但不能依赖它在现代浏览器中起效 - 检查是否启用 SW：打开 DevTools → Application → Service Workers，确认状态为 “Activated and is running”；若显示 “Waiting”，说明
self.skipWaiting()没调用或clients.claim()缺失
复杂点在于：manifest 和 SW 不是互斥升级关系，而是两套独立机制。你在同一页面上既写 manifest 又注册 SW，浏览器会优先使用 SW，manifest 形同虚设——除非你刻意让它在 SW 失效时兜底。这种混合模式反而增加调试成本，不如一步到位切到 SW。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
