Web Storage 与 HTML5 离线缓存（AppCache，已废弃）定位不同：前者存储结构化数据（如用户偏好、token），后者缓存静态资源（如 HTML/CSS/JS）；现已被 Service Worker + Cache API 取代，分工更清晰。
Web Storage 和 HTML5 离线缓存（Application Cache，已废弃）是两类不同层级、不同目标的本地存储机制，不能互相替代，但可协同使用：前者存的是“数据”，后者存的是“资源”。
核心定位不同：一个管数据，一个管文件
Web Storage（localStorage 和 sessionStorage）用于在浏览器中持久或临时保存结构化数据，比如用户偏好、表单草稿、token、主题设置等。它只支持字符串键值对，操作全靠 JavaScript API，不参与页面加载流程。
HTML5 离线缓存（即 AppCache）本质是一套静态资源预加载机制，通过 manifest 文件声明哪些 HTML/CSS/JS/图片等需缓存，让整个页面在无网络时仍能打开。它不存业务数据，只缓存可执行的静态文件。
- Web Storage 存的是 运行时产生的状态数据
- AppCache 存的是 开发时预设的页面资源
- 前者由 JS 主动读写；后者由浏览器按 manifest 自动管理
生命周期与作用范围差异明显
localStorage 数据默认永久保留，除非手动调用 clear() 或用户清除站点数据；sessionStorage 仅限当前标签页会话，关闭即失。两者都严格遵循同源策略，跨协议、域名、端口均不可访问。
立即学习“前端免费学习笔记（深入）”；
AppCache 的缓存生命周期依赖 manifest 文件内容变更：只有当 manifest 文件本身被修改（哪怕只加个空格），浏览器才会重新下载并更新整个缓存组。它没有“过期”概念，但一旦 manifest 不再更新，缓存就永远不变——这也是它被弃用的重要原因。
- localStorage/sessionStorage 可随时增删改查，响应实时业务逻辑
- AppCache 更新被动且粗粒度，无法按需刷新某个资源
- AppCache 缓存失败时可能整站白屏，而 Web Storage 失败只影响局部功能
现代替代方案已明确分工
AppCache 已被标准废弃，取而代之的是 Service Worker + Cache API，它更灵活、可控、可编程。此时，分工更清晰：
- Cache API 负责缓存网络请求（HTML、JS、CSS、图片等静态资源）
- Web Storage 继续负责用户数据、界面状态、轻量级配置
- 需要结构化、事务性或大量数据时，可升级到 IndexedDB
例如：一个离线笔记应用，用 Cache API 缓存编辑器界面和脚本，确保离线可打开；用 localStorage 保存用户最近几条草稿；用 IndexedDB 存储全部笔记及附件。
它们能互补，但不是叠加关系
Web Storage 不解决页面打不开的问题，AppCache（或 Service Worker）也不解决“用户上次选了深色模式”这种状态记忆问题。真正的互补在于：一个让页面“能运行”，一个让运行“有记忆”。
实际开发中，常组合使用：
- Service Worker 拦截 fetch 请求，优先返回 Cache API 缓存的资源
- 页面加载后，从 localStorage 读取用户主题、语言、折叠状态并立即应用
- 编辑过程中，定时将草稿存入 sessionStorage，防止意外刷新丢失
不复杂但容易忽略：资源缓存解决可用性，数据存储解决一致性，二者缺一不可。
