浏览器存储配额是分层动态管理体系，含全局（占磁盘50%）、组（同主域共享，20%上限）、临时（localstorage等约300mb）三级结构，超限会静默删除数据而非报错。
浏览器存储配额不是“用完才报警”的静态水桶，而是分层、动态、带驱逐逻辑的资源管理体系。数据被悄悄删除，往往不是因为写满了，而是触发了浏览器的自动清理机制——比如跨源组空间不足时整站数据被清空，或隐私模式下写入即失效。关键要读懂三层配额逻辑和对应的“静默失效点”。
看懂三级配额结构：全局→组→临时
浏览器按“源（Origin）”管理数据，但配额分三档控制：
- 全局限制：取决于设备空闲磁盘，Chrome 默认最多占用可用空间的 50%；达到后，浏览器会整站删除最久未访问的网站数据（不是删部分，是整个 origin 下的 IndexedDB + Cache + localStorage 全清）
- 组限制：同一主域名（如 example.com 及其所有子域）共享一个“组”，上限为全局限制的 20%，最低 10 MB、最高 2 GB；这是硬限制，超限后任何写入直接失败，不警告也不自动清理旧数据
- 临时配额：localStorage/sessionStorage 属于“临时存储”，无用户明确授权时，Chrome 初始只给约 300 MB，且在开启“关闭窗口时清除网站数据”选项时会被进一步压缩
识别静默删除的高危场景
以下情况不会抛错，但数据可能已不可靠或已被移除：
- Safari 无痕模式下 localStorage 存在但无法写入——检测不能只查
typeof localStorage !== 'undefined'，必须执行“写→读→删”闭环测试 - IndexedDB 打开时
event.newVersion === null，常因组配额满导致初始化失败，此时数据库根本没建起来，后续所有操作都无效 - Chrome 启用了“关闭窗口时清除网站数据”，每次关浏览器都会清掉临时存储，但 Service Worker 缓存和 IndexedDB 可能残留，造成状态不一致
- 多个子域名（如 app.example.com 和 api.example.com）共用同一组配额，其中一个疯狂写日志，会导致另一个的缓存被系统静默驱逐
主动监控与防御性写入策略
不依赖浏览器提示，自己掌握空间水位：
- 用
navigator.storage.estimate()定期获取usage和quota，当使用率 >85% 时主动触发清理（如删除 7 天前日志） - 对 localStorage 做试探写入：生成 1 MB 占位字符串并立即删除，捕获
QuotaExceededError判断是否濒临耗尽 - 所有写入操作必须包裹 try-catch，并准备 fallback：失败时降级到内存 Map，同时记录日志并提示用户“离线数据暂未保存”
- 敏感数据（如 token）避免直存 localStorage；拆分处理：短期 access_token 放 sessionStorage，长期 refresh_token 加密后存 IndexedDB 并设 TTL 索引
规避组配额挤占的实操建议
一个域名下的多个前端项目容易互相踩坑：
- 将不同业务子域隔离为独立源：用
app-v1.example.com和app-v2.example.com替代app.example.com/v1和app.example.com/v2，避免共享组配额 - 大体积缓存（如离线资源包）统一走 IndexedDB，不用 localStorage；前者支持事务、分片、游标遍历，后者同步阻塞且容量瓶颈明显
- 若需更高保障，调用
navigator.storage.persist()申请持久化权限——需用户点击确认，成功后可突破默认临时配额，获得数 GB 级空间
