我们把浏览器世界拆成两类：能记东西的仓库，和能在后台干活的工人。把这两类用顺了，离线、缓存、推送、同步这些“高配功能”就顺着来了。
1）全景框架：两类能力，一个脑回路
浏览器侧的能力可以被拉成一条主线：
- 仓库——负责“记住你”：Cookie、localStorage、sessionStorage、IndexedDB、Cache Storage、Storage Buckets（更细的分区与清理思路）、File System Access API（需授权的本地读写）、以及 JS 运行期的内存；WebSQL 已退役。
- 工人——负责“替你干”：Service Worker（离线、请求拦截、缓存、推送、后台同步的总调度），再加上 Web Worker/Shared Worker（多线程）和 BroadcastChannel（多页面通信），Push API & Background Sync 则把“消息/断网重试”带进来。
一句话：选仓库存什么，派工人怎么干。
2）主角速读：用人话把定位说清
Cookie 是会自动随请求上报的小纸条，空间小（≈4KB），适合登录 session 这类“服务端需要每次知道你是谁”的状态。
localStorage 是“本机小仓库”，永久保存（除非清理），同步 API，体量在 ≈5–10MB，用来放偏好设置、轻量缓存。
sessionStorage 与 localStorage 相似，但只活在当前 tab，tab 关了就没了，适合一次性流程的临时上下文（比如分步表单中间态）。
IndexedDB 是浏览器内的 NoSQL 仓库，可放大量结构化数据（几十 MB 到几百 MB），异步 API，离线应用与 API 数据缓存的主力。
Cache Storage 是给 Service Worker 用的“资源仓库”，存 HTTP Response（HTML/JS/CSS/图片等），容量同样能到几百 MB 量级，离线访问与精细缓存策略离不开它。
Service Worker 是浏览器的“小代理服务器”：拦截 fetch、裁决缓存/网络、做离线、收推送、跑后台同步，生命周期独立于页面。
Web Worker / Shared Worker 让计算去后台线程跑（Shared 还能跨 tab 共享），不碰 DOM，负责把主线程从重活里解放出来。
BroadcastChannel 是小喇叭，多页面/worker 之间直接广播消息，同步登录态、主题这类全局事件很顺手。
Push API 让页面关了也能被叫醒（通过 Service Worker 展示通知或做更新）。
Background Sync 让“地铁里点了也算”成为可能：断网时先记账，联网后自动补交。
Storage Buckets 把不同类型数据分区、清理更可控（仍在推广中）。
File System Access API 在用户授权下读写本地文件，做在线编辑器这类场景更像桌面应用。
WebSQL 已废弃，不推荐。
JS 运行期内存（变量、Map 等）只在当前会话存活，刷新就没了，是“工作记忆”，不是持久化。
3）容量与特性对照
| 能力 | 典型用途 | 容量/级别（约） | 关键特性 |
|---|---|---|---|
| Cookie | 登录 session / 每次随请求上报 | ~4KB | 自动随请求发送到服务器 |
| localStorage | 用户偏好、轻量缓存 | ~5–10MB | 永久保存、同步 API |
| sessionStorage | 当前 tab 的临时数据 | ~5MB | 关 tab 即清空 |
| IndexedDB | 结构化/大量业务数据、离线数据 | 50MB–数百MB | 异步 NoSQL 仓库 |
| Cache Storage | 静态资源与离线页面 | 数百MB量级 | 存 HTTP Response，配 SW 做策略 |
| Service Worker | 离线/缓存/推送/后台同步 | - | 拦截 fetch，生命周期独立页面 |
| Web/Shared Worker | 后台计算、多 tab 共享 | - | 不操作 DOM |
| BroadcastChannel | 多页面/worker 通信 | - | 广播式同步状态 |
| File System Access API | 授权后的本地文件读写 | - | 更像桌面应用 |
| Storage Buckets | 存储分区与清理策略 | - | 仍在推广中 |
| WebSQL | （历史） | - | 已废弃 |
4）怎么选：三步不纠结
第一步：想清楚“谁需要看到这些数据” 。
如果服务端每次都要知道（比如登录态），就交给 Cookie。如果主要是本地自己用，再看下面两步。
第二步：判断数据“多不多、久不久” 。
少量、简单又要久：localStorage；只在当前 tab：sessionStorage；量大还结构化：IndexedDB。
第三步：页面是否要“没网也能开” 。
要离线与资源级别的缓存：Service Worker + Cache Storage。数据级别离线再加 IndexedDB。需要消息/断网补交，就把 Push API/Background Sync 一并纳入。
5）标准组合拳：把离线体验做“像真的一样”
Service Worker 决策所有网络请求的去向。它先看 Cache Storage 是否已有命中的 HTTP Response；有就直接用，没有就走网络；网络成功后再把最新内容写回缓存。
页面里的业务数据（比如“文章列表”“表单草稿”）走 IndexedDB，这样没网时依然能渲染“最后一次成功的数据”。
如果用户在没网时触发了提交，Background Sync 负责把这笔“欠账”记录下来，网络恢复再由 Service Worker 自动补发。
要通知用户有更新或者提醒回流，就用 Push API；即便页面关闭，也能被叫醒处理。
这套流程的关键词只有四个：拦截、命中、回写、补交。
6）实践里的边界与心法
- Cookie 只放“必须让服务端知道”的小状态，否则浪费带宽。
- localStorage 别塞大对象，超过它的范畴就上 IndexedDB。
- Cache Storage 放资源，IndexedDB 放数据，两者职责清晰，排障更容易。
- Worker 不碰 DOM；想要跨页面共享，就考虑 Shared Worker/BroadcastChannel。
- File System Access API 的前提是用户授权；适合“打开/另存为”类交互，而不是偷读文件。
- WebSQL 历史包袱，新项目直接略过。
