关键在于理清“数据存哪、谁来管、能存多少、何时失效”四条主线：localStorage/sessionStorage存轻量键值对，Cache API专缓网络资源，IndexedDB支持结构化大数据，Storage Buckets实现分桶配额与持久策略精细化管理。
要真正掌握现代 Web 客户端存储与配额管理的底层原理，关键不是背API，而是理清“数据存哪、谁来管、能存多少、何时失效”这四条主线。它本质是浏览器在有限本地资源下，为不同用途的数据建立的一套分层治理机制。
理解存储技术的分层定位
每种存储方案解决的问题不同，不能混用：
- localStorage / sessionStorage：轻量键值对，5MB左右，同步阻塞，适合用户偏好、简单状态；sessionStorage 关闭即丢，不跨标签页
- Cache API：专为网络资源设计（HTML/CSS/JS/图片），必须配合 Service Worker 使用，支持精确缓存控制和离线访问
- IndexedDB：结构化数据库，异步、大容量（可达数百MB）、支持事务和索引，适合聊天记录、离线文档、图层数据等复杂场景
-
Storage Buckets（新标准）：把上述能力进一步组织化——可为“用户数据”“缓存”“临时文件”分别建桶，每个桶有独立配额、持久策略（
durability: 'strict'或'relaxed'）和清理规则
吃透配额的三级计算逻辑
浏览器不是给固定数字，而是动态协商的结果：
- 总配额：基于设备空闲磁盘空间估算（如移动端常取总存储的50%），并非硬编码
- 起源配额：同一协议+域名+端口视为一个“起源”，Chrome 默认分配总配额的10%，但可被 Storage Buckets 覆盖
-
临时配额：通过
navigator.storage.estimate()获取实时使用量与当前可用上限，注意它返回的是估算值，非绝对精确
配额不足时，浏览器不会直接报错，而是触发 QuotaExceededError 或静默失败（尤其在 IndexedDB 写入时），需主动监听并降级处理。
区分持久性与生命周期控制
“存在”不等于“永存”。浏览器会按策略清理：
- 非持久化存储（如默认 Cache、部分 IndexedDB）：可能被系统自动清除（如低磁盘空间、长时间未访问）
-
持久化请求：调用
navigator.storage.persist()可申请豁免自动清理，但用户有权拒绝；Storage Buckets 中显式设置persisted: true是更细粒度的替代方案 -
手动清理边界：localStorage.clear() 不影响其他起源；IndexedDB.deleteDatabase() 仅删指定库；而 Storage Buckets 提供
bucket.delete()实现桶级原子清理
关注新旧机制的协同与演进
Storage Buckets 不是取代旧API，而是封装与编排：
- 传统方式中，localStorage、IndexedDB、Cache 共享同一套起源配额，互相挤占
- Buckets 把它们“隔离到不同房间”，例如：
user-data桶设 100MB + 持久化，cache-data桶设 500MB + 可被清理，互不影响 - 目前 Chrome 已支持，Firefox 和 Safari 正在跟进；生产环境可用，但需做降级（检测
navigator.storageBuckets是否存在）
