Web Storage 存储空间与浏览器配额管理机制解析

主流浏览器单源Web Storage配额为：Chrome/Edge约2.5–5MB、Firefox固定5MB（按一级域名共享）、Safari约5MB（隐私模式禁用），超限抛QuotaExceededError；sessionStorage容量同localStorage但不持久；配额无API可查，需试探写入检测，且严格遵循同源策略隔离。

Web Storage（包括 localStorage 和 sessionStorage）的存储空间不是无限的，而是受浏览器配额机制严格管理。它不按“总硬盘剩余空间”分配，而是以“每源（origin）独立限额”方式运作，且不同浏览器策略差异明显——理解这点，才能避免数据写入失败、静默丢弃或跨标签页同步异常。

每个域名的存储上限是多少？

当前主流浏览器对单个源（协议+域名+端口）的 Web Storage 配额如下（截至2026年中）：

1. Chrome / Edge（基于Chromium）：约 2.5 MB～5 MB，实际值动态浮动，取决于可用磁盘空间与当前总存储压力；超出时 setItem() 会抛出 QuotaExceededError 异常，而非静默失败。
2. Firefox：固定 5 MB，但按一级域名（如 example.com）统一分配——a.example.com 和 b.example.com 共享这 5 MB。
3. Safari（iOS/macOS）：约 5 MB，但在隐私浏览模式下完全禁用 localStorage；若用户启用“阻止所有 Cookie”，Web Storage 也可能被限制或清空。
4. 注意：sessionStorage 不计入配额总额，但它绑定于单个标签页生命周期，容量限制与 localStorage 相同，只是不持久化。

配额是如何动态计算和触发限制的？

浏览器不会预先划死“5 MB”硬边界，而是采用“软配额 + 垃圾回收”机制：

1. 写入时检查当前源已用空间 + 新数据大小是否接近阈值；接近时可能触发内部清理（如移除最久未访问的键值对），但不保证成功。
2. 当配额耗尽，localStorage.setItem(key, value) 会立即抛出错误，getItem() 仍可读取旧数据，removeItem() 和 clear() 依然有效——这是主动释放空间的关键入口。
3. 没有 API 能直接查询剩余配额，但可通过试探写入 + 错误捕获粗略估算；Chrome DevTools → Application → Storage 可直观查看各 origin 实际占用。

同源策略如何影响存储隔离？

Web Storage 严格遵循同源策略（Same-Origin Policy），这是配额管理的基础逻辑：

1. https://a.example.com 和 https://b.example.com 视为两个独立源，各自拥有完整配额（Chrome/Firefox 行为不同，见上条）。
2. http://example.com 与 https://example.com 完全隔离——协议不同即不同源，存储不共享，配额不叠加。
3. 子域名间（如 shop.example.com 和 blog.example.com）默认不共享数据，除非显式通过 document.domain = "example.com" 协调（仅限 document 级，且仅对旧式 iframe 场景有效；现代推荐用 postMessage）。

开发者该如何安全使用 Web Storage？

避免因配额问题导致功能降级，需从设计层面应对：

1. 写入前做 try/catch 包裹，捕获 QuotaExceededError 并触发清理逻辑（如删过期项、压缩 JSON 数据、降级到 sessionStorage）。
2. 复杂对象务必 JSON.stringify() 存储，读取后 JSON.parse() 还原；避免直接存函数、undefined、Date 对象等无法序列化的值。
3. 定期清理无用键：可约定 key 命名规则（如加时间戳前缀），或维护一个元数据索引表记录有效期。
4. 敏感设置类数据（如主题、语言）适合用 localStorage；临时状态（如表单草稿、token）优先用 sessionStorage，天然规避配额累积。