主流浏览器单源Web Storage配额为：Chrome/Edge约2.5–5MB、Firefox固定5MB（按一级域名共享）、Safari约5MB（隐私模式禁用），超限抛QuotaExceededError；sessionStorage容量同localStorage但不持久；配额无API可查，需试探写入检测，且严格遵循同源策略隔离。
Web Storage（包括 localStorage 和 sessionStorage）的存储空间不是无限的，而是受浏览器配额机制严格管理。它不按“总硬盘剩余空间”分配，而是以“每源（origin）独立限额”方式运作，且不同浏览器策略差异明显——理解这点，才能避免数据写入失败、静默丢弃或跨标签页同步异常。
每个域名的存储上限是多少？
当前主流浏览器对单个源（协议+域名+端口）的 Web Storage 配额如下（截至2026年中）：
-
Chrome / Edge（基于Chromium）：约 2.5 MB～5 MB，实际值动态浮动，取决于可用磁盘空间与当前总存储压力；超出时
setItem()会抛出QuotaExceededError异常，而非静默失败。 -
Firefox：固定 5 MB，但按一级域名（如
example.com）统一分配——a.example.com和b.example.com共享这 5 MB。 - Safari（iOS/macOS）：约 5 MB，但在隐私浏览模式下完全禁用 localStorage；若用户启用“阻止所有 Cookie”，Web Storage 也可能被限制或清空。
- 注意：sessionStorage 不计入配额总额，但它绑定于单个标签页生命周期，容量限制与 localStorage 相同，只是不持久化。
配额是如何动态计算和触发限制的？
浏览器不会预先划死“5 MB”硬边界，而是采用“软配额 + 垃圾回收”机制：
- 写入时检查当前源已用空间 + 新数据大小是否接近阈值；接近时可能触发内部清理（如移除最久未访问的键值对），但不保证成功。
- 当配额耗尽，
localStorage.setItem(key, value)会立即抛出错误，getItem()仍可读取旧数据，removeItem()和clear()依然有效——这是主动释放空间的关键入口。 - 没有 API 能直接查询剩余配额，但可通过试探写入 + 错误捕获粗略估算；Chrome DevTools → Application → Storage 可直观查看各 origin 实际占用。
同源策略如何影响存储隔离？
Web Storage 严格遵循同源策略（Same-Origin Policy），这是配额管理的基础逻辑：
-
https://a.example.com和https://b.example.com视为两个独立源，各自拥有完整配额（Chrome/Firefox 行为不同，见上条）。 -
http://example.com与https://example.com完全隔离——协议不同即不同源，存储不共享，配额不叠加。 - 子域名间（如
shop.example.com和blog.example.com）默认不共享数据，除非显式通过document.domain = "example.com"协调（仅限 document 级，且仅对旧式 iframe 场景有效；现代推荐用 postMessage）。
开发者该如何安全使用 Web Storage？
避免因配额问题导致功能降级，需从设计层面应对：
- 写入前做
try/catch包裹，捕获QuotaExceededError并触发清理逻辑（如删过期项、压缩 JSON 数据、降级到 sessionStorage）。 - 复杂对象务必
JSON.stringify()存储，读取后JSON.parse()还原；避免直接存函数、undefined、Date 对象等无法序列化的值。 - 定期清理无用键：可约定 key 命名规则（如加时间戳前缀），或维护一个元数据索引表记录有效期。
- 敏感设置类数据（如主题、语言）适合用 localStorage；临时状态（如表单草稿、token）优先用 sessionStorage，天然规避配额累积。
