localstorage和sessionstorage存储容量非固定5mb，而是动态值，取决于浏览器、平台与系统状态；二者共享同源配额，超限时setitem()抛出quotaexceedederror。
localStorage 和 sessionStorage 的存储容量不是固定不变的“5MB”一刀切，而是受浏览器实现、操作系统、可用磁盘空间及同源策略下其他存储占用情况共同影响的动态值。
实际容量取决于浏览器与环境
主流现代浏览器（Chrome、Firefox、Edge、Safari）对单个源（origin）的 Web Storage 总配额通常在 5–10 MB 区间，但这个数字是软限制，并非硬性上限：
- Chrome 实际采用基于总磁盘空间的配额算法：初始配额约 5MB，但可随页面活跃度和用户行为动态提升（最高可达数十 MB），前提是磁盘有余量且未触发清理机制；
- Safari 在 macOS/iOS 上默认更保守，常为 5MB，且在隐私模式或低存储设备上可能进一步压缩；
- Firefox 使用固定配额模型，多数版本设为 10MB，但可通过
dom.storage.default_quota配置项调整； - 移动端 WebView（如 Android Chrome WebView、iOS WKWebView）可能继承系统限制，部分定制内核会将配额降至 2–3MB。
localStorage 与 sessionStorage 共享同一配额池
二者不各自独立分配容量，而是共用同一个“同源存储配额”。这意味着：
- 若 localStorage 已使用 4.8MB，sessionStorage 最多只能再写入约 200KB（假设总配额为 5MB）；
- 调用
setItem()超出配额时，浏览器抛出QuotaExceededError异常，不会静默失败； -
localStorage.length和sessionStorage.length只反映键值对数量，不体现字节占用——一个长字符串可能占数 MB，而百个短键只占几 KB。
如何探测真实可用容量
没有标准 API 直接读取剩余配额，但可通过试探法估算：
- 用递增长度的字符串反复
setItem，捕获首次报错的位置； - 利用
navigator.storage.estimate()（需 HTTPS + Storage API 启用）获取粗略估算：navigator.storage.estimate().then(({usage, quota}) => console.log('已用', usage, '总配额', quota))； - 注意：该 API 返回的是整个站点（含 Cache API、IndexedDB 等）的综合配额，非 Web Storage 专属值。
容量超限的典型表现与应对
超出限制时行为一致，但后果需主动处理：
- 写入失败不触发事件，必须用
try...catch捕获QuotaExceededError； - 建议策略：优先清理过期/冗余项（如带时间戳的缓存），再尝试写入；
- 对大对象（如用户导出数据），应先序列化评估长度：
new TextEncoder().encode(JSON.stringify(data)).length，避免盲目塞入； - 长期方案：超 1MB 数据考虑迁移到 IndexedDB，它支持事务、查询和更大容量（通常数百 MB 起）。
