javascript 无法直接获取 localstorage 容量，需通过试探写入+异常捕获动态探测；实际容量因浏览器而异（chrome 约 10 mb，ios safari 可能骤降至 0）；计量单位为 utf-8 字节，须用 textencoder 精确计算并预留 10% 余量；navigator.storage.estimate() 不适用，超限时应降级至 indexeddb 或内存 map。
JavaScript 中无法直接读取 localStorage 的最大容量，浏览器不提供 remainingSpace 或 maxSize 这类 API。所谓“5MB”只是历史参考值，实际可用空间高度动态：Chrome 桌面版通常约 10 MB，Firefox 约 5–10 MB，iOS Safari 在内存紧张时可能骤降至 0，微信 X5 内核实测甚至不足 1 MB。检测必须依赖运行时试探写入 + 异常捕获，而非静态估算或字符串长度粗算。
用试探写入法动态探测上限
核心思路是不断拼接字符串并尝试写入，直到触发 QuotaExceededError。关键细节：
- 起始块建议用 10 KB（10240 字节）的 ASCII 字符串，避免 UTF-8 编码干扰
- 每次拼接后立即调用
localStorage.setItem('probe', data)，失败即终止 - 务必在
try-catch中捕获err.name === 'QuotaExceededError'，不能只看err.code === 22（部分旧浏览器不兼容） - 成功后及时
removeItem('probe')，避免污染真实数据
按 UTF-8 字节精确预估，不是字符长度
localStorage 计费单位是 UTF-8 字节，不是 JavaScript 字符数。一个中文字符占 2 字节，一个 emoji 占 4 字节，key 名、JSON 引号、空格全计入。错误做法：JSON.stringify(obj).length；正确做法：
-
new TextEncoder().encode(str).length获取真实字节数 - 对 key 和 value 分别编码再求和，例如：
TextEncoder().encode(key).length + TextEncoder().encode(value).length - 预估时预留至少 10% 余量，防止因浏览器内部元数据开销误判
避免依赖 navigator.storage.estimate()
该 API 返回的是整个 origin（含 IndexedDB、Cache 等）的粗略估算，且仅在 HTTPS 或 localhost 下可用：
- 隐身模式下常返回极小值（如 128 MB），与 localStorage 实际剩余严重不符
- 无法区分各类存储的占用比例，不能用于精准判断 localStorage 是否将满
- 它适合做长期趋势参考，但不能替代试探写入作为实时容量判断依据
超额时优先降级，不硬扛
localStorage 是同步、字符串-only、容量封顶的简易方案。当单条数据超 100 KB 或总量逼近 5 MB 时，应主动切换：
- 降级到 IndexedDB：Chrome 初始配额约 50–250 MB，支持
navigator.storage.estimate()更稳定估算 - 临时存入内存 Map：适用于页面生命周期内的状态（如表单草稿），避免丢失
- 分片存储：对大对象切片（每片 ≤ 100 KB），配合命名规则如
data_123_part0
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
