localstorage实际存储上限非固定值，而是受浏览器（chrome/edge约5–10mb、firefox约5mb、ios safari低至2.5mb）、编码方式（utf-16字符计数）、字符类型及已用空间共同影响；准确检测需通过试探写入并捕获quotaexceedederror，而非依赖length或序列化估算；超限时应优先采用压缩（如lzstring）+分片（≤900kb/块）策略，或升级至indexeddb以支持更大容量与结构化操作。
LocalStorage 的实际存储上限不是固定数字，而是受浏览器实现、编码方式、字符类型（ASCII vs Unicode）和当前已用空间共同影响。主流浏览器通常在 5–10 MB 区间浮动，Edge 和 Chrome 多为 5120 KB（即 5 MB），但部分版本或隐私模式下可能低至 2.5 MB 或高至 10 MB。单纯靠 localStorage.length 或 JSON.stringify(localStorage).length 无法准确判断剩余容量——前者只计键数量，后者序列化过程本身可能触发异常。
真实容量检测：用试探写入代替预估
最可靠的方式是“写入测试 + 异常捕获”：
- 生成一段小数据（如
"test"或 100 字符随机字符串） - 尝试存入一个临时键（如
"__quota_test__"） - 若抛出
QuotaExceededError，说明已接近满载 - 成功后立即删除该测试项，避免污染实际数据
不建议依赖 localStorage.key(i) 遍历估算总字节数——Unicode 字符（如中文）在 UTF-16 编码下占 2 字节，而 .length 返回的是字符数，不是字节数，误差可达 100%。
分片存储方案：绕过单条 5MB 瓶颈
当单个数据对象（如一篇富文本笔记、一张 Base64 图片）本身超过 5 MB，或整体缓存需远超限额时，分片是最轻量、兼容性最强的解法：
- 先将原始数据
JSON.stringify()转为字符串 - 按安全块大小切分（推荐 ≤ 900 KB/块，预留缓冲空间）
- 用统一前缀 + 序号命名分片键，例如
"note_abc123_chunk_0"、"note_abc123_chunk_1" - 额外保存元数据键（如
"note_abc123_meta"），记录总块数、块大小、原始长度 - 读取时按序拼接所有分片，再
JSON.parse()还原
注意：不要用 substring() 在中文或 emoji 字符中间截断，应确保每块末尾是完整 UTF-16 编码单元；更稳妥的做法是先转成 Uint8Array 再按字节切分，但对多数业务场景，900 KB 安全阈值已足够避开边界问题。
压缩 + 分片：双管齐下提升有效容量
对文本类数据（JSON、Markdown、日志），LZ-string 压缩可显著降低体积：
- 典型压缩率 50–80%，即 5 MB 原始数据压缩后常低于 2 MB
- 压缩后再分片，既减少块数，也降低单次写入失败概率
- 推荐组合用法：
LZString.compressToUTF16()输出仍是字符串，可直接存入 localStorage，解压时用LZString.decompressFromUTF16() - 避免对已压缩格式（如 JPEG、MP4 Base64）重复压缩，无效且耗性能
何时该换 IndexedDB 而非硬扛 localStorage
分片和压缩能延展 localStorage 生命线，但不是万能解：
- 频繁增删改 >100 个分片时，遍历和拼接开销明显上升
- 需事务、索引、模糊搜索或二进制文件（Blob）存储时，localStorage 无法满足
- 目标用户集中在较新浏览器（Chrome 24+/Firefox 16+/Edge 12+），IndexedDB 兼容性已足够好
- 搭配
localForage库可无缝降级：优先用 IndexedDB，退化时自动 fallback 到 localStorage + 分片
真正的大容量场景（离线音视频、百兆级本地数据库），应从架构设计初期就选用 IndexedDB，而非把 localStorage 当主力存储去“打补丁”。
