HTML无内置缓存机制，离线能力由Service Worker决定；Application Cache已全量废弃；SW需在install阶段缓存完整依赖链，fetch事件中须按请求类型分层处理，并在activate阶段主动清理旧缓存。
HTML 本身对缓存机制**没有内置要求**，也不会主动参与缓存决策——它只是被缓存的资源之一。真正决定“能否离线”“缓存是否生效”的，是 Service Worker 的注册、安装与拦截逻辑，不是 HTML 文件里写了什么标签或 meta。
为什么加了 manifest 属性也没用
因为现代浏览器（Chrome 94+、Firefox 84+、Safari iOS 16.4+）已**完全移除 Application Cache 支持**。 这行代码在当前环境里纯属无效，连控制台警告都不会触发，静默失效。
- 服务器返回的
.appcache文件即使 MIME 类型正确（text/cache-manifest），浏览器也直接忽略 -
window.applicationCache在新浏览器中是undefined，调用swapCache()会报错 - 哪怕旧设备还能跑，只要任一缓存资源 404 或跨域，整个清单加载就静默失败，不提示、不重试
Service Worker 的 install 阶段必须缓存完整依赖链
只缓存 /index.html 是最常见错误。离线时 HTML 加载成功，但里面的 <script src="app.js"></script> 或 import './style.css' 404，页面白屏或功能缺失。
- 用
cache.addAll(['/', '/app.js', '/style.css', '/logo.png'])，路径必须是根相对路径（/表示站点根目录） - 避免缓存带查询参数的 URL，比如
/data.json?v=1.2和/data.json?v=1.3被视为两个不同键，浪费空间且易混乱 -
install事件中缓存的内容，仅对**后续访问**生效；首次访问时 SW 已注册，但缓存还没建好
fetch 事件里不能无差别匹配所有请求
写成 event.respondWith(caches.match(event.request)) 看似省事，实际会破坏登录态和表单提交。
立即学习“前端免费学习笔记（深入）”；
-
event.request.destination === 'document'是识别 HTML 页面请求的唯一可靠方式（地址栏输入、链接跳转） - POST 请求、带
credentials: 'include'的 fetch、API 接口等，不该走 cache.match()，否则导致静默失败或数据错乱 - 建议分层处理：HTML 走缓存优先（Stale-While-Revalidate），静态资源走 cache-only，API 走 network-only 或带 fallback
最容易被忽略的一点：缓存清理不是自动发生的。HTML 文件更新了，Service Worker 不显式在 activate 事件里调用 cache.delete() 并剔除旧版本缓存名，用户永远看不到新内容——哪怕你改了十次 index.html，浏览器仍从老缓存里读。
