HTML5客户端存储不存在跨浏览器统一配额标准，各厂商基于安全策略、设备类型等动态分配；开发应采用试探探测、均值估算和分层降级策略，避免硬编码阈值或依赖不稳定的estimate() API。
HTML5 客户端存储没有、也不可能有跨浏览器统一的配额标准。各厂商（Chrome、Safari、Firefox、Edge）基于自身安全策略、设备类型、隐私模式和磁盘空间动态分配配额，这是设计使然，不是缺陷——你无法“统一”它，只能适配它。
为什么不存在统一配额
浏览器厂商不共享配额算法，也不承诺兼容性：
- Chrome 对 IndexedDB 可分配至空闲磁盘的 60%，但首次打开常限 50–100 MB；桌面 localStorage 通常 10 MB，Android Chrome 却可能仅 2–5 MB
- Safari（尤其是 iOS）对 localStorage 严格限制在约 5 MB，且隐身模式下直接禁用；IndexedDB 在 iOS Safari 中长期存在写入延迟与静默失败问题
- Firefox 采用“按站点总和”策略，localStorage + IndexedDB + Cache API 共享一个浮动配额池（通常 200–500 MB），但无明确文档说明计算逻辑
- Edge 行为基本跟随 Chromium，但在企业策略或组策略启用时可能进一步收紧
实际开发中该怎么做
放弃“统一标准”的想法，转向可测量、可降级、可预估的运行时策略：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
-
试探性容量探测：向 localStorage 写入 1 MB 随机字符串，捕获
QuotaExceededError判断是否临近上限；IndexedDB 可在upgradeneeded或blocked事件中结合event.newVersion === null推断初始化失败是否由空间不足导致 - 主动计数+均值估算：维护本地写入条目数 + 平均单条大小（如用户上传图片平均 800 KB），在写入前做软性预检：“已存 42 条 → 约占 33.6 MB”，超过阈值（如 80% 预估上限）即触发自动清理
-
分层 fallback 链路：localStorage 失败 → 降级至内存 Map；IndexedDB 批量写入失败 → 拆成每次 20 条重试 + 删除 7 天前日志；全链路不可用（如 Safari 隐身）→ 将关键状态序列化进 URL hash 或利用
beforeunload尝试暂存 sessionStorage（部分浏览器仍允许）
别踩的坑
有些做法看似“统一”，实则危险或无效：
立即学习“前端免费学习笔记（深入）”；
- 硬编码 10 MB 作为所有浏览器的判断阈值 → iOS Safari 会提前报错，Chrome 移动端可能更早耗尽
- 依赖
navigator.storage.estimate()期望获得精确剩余空间 → 该 API 返回值极粗略（Chrome 返回{usage: xxx, quota: yyy}，但 quota 常为 0 或远高于实际可用值；Safari 不支持，Firefox 返回值不稳定） - 试图用 SharedStorage、document.domain 或第三方 Cookie 绕过配额隔离 → 这些要么已弃用，要么根本与配额无关，还引入安全风险
