localStorage无统一容量上限，实际空间取决于浏览器、平台与系统状态；超限时setItem()抛出QuotaExceededError；需用TextEncoder计算UTF-8字节长度并预留余量；应试探+异常捕获双保险；清理须按前缀、过期、损坏精准剔除；大数据应降级至IndexedDB或分片存储。
Web Storage（主要是 localStorage）没有统一容量上限，实际可用空间因浏览器、平台和系统状态而异，检测与超额处理必须结合试探写入、异常捕获和分级降级，不能依赖固定数值或静态估算。
真实容量取决于运行时环境
所谓“5MB”只是历史建议值，早已失效。Chrome 和 Edge 桌面版通常提供约 10 MB，Firefox 约 5–10 MB，iOS Safari 在内存紧张时可能骤降至 0，微信 X5 内核实测甚至不足 1 MB。这些数值不是配置项，而是浏览器根据设备空闲空间、隐私模式、同源策略动态分配的结果。
关键点：
- localStorage 按 UTF-8 字节计费，不是 JavaScript 字符长度 —— 一个中文字符占 2 字节，一个 emoji 占 4 字节；
- key 名、JSON 引号、空格都计入字节，预估时应预留至少 10% 余量；
- 不能用
JSON.stringify(obj).length判断容量，需用new TextEncoder().encode(str).length获取真实字节数。
运行时检测靠试探+异常，而非查询 API
浏览器不提供 remainingSpace 这类接口，navigator.storage.estimate() 虽可返回 usage 和 quota，但它是 origin 级别的粗略估算（含 IndexedDB、Cache 等所有存储），且仅在 HTTPS 或 localhost 下可用，隐身模式下常返回极小值（如 128 MB），无法精准反映 localStorage 当前可用空间。
更可靠的做法是轻量试探：
- 写入一个短字符串（如
localStorage.setItem('probe', 'x')），成功后立即removeItem('probe')； - 所有
setItem()必须包裹try-catch，专门检查err.name === 'QuotaExceededError'或err.code === 22； - 捕获后不应直接清空全部数据，而应触发定向清理（如删除
cache_前缀项、过期项或解析失败的损坏项）。
超额时优先降级，而非硬扛
localStorage 是同步、字符串-only、容量封顶的简易方案，不适合承载大数据。当单条数据超 100 KB 或总量逼近 5 MB 时，应主动切换技术栈：
- 降级到 IndexedDB：支持更大配额（Chrome 可达空闲磁盘的 60%，初始约 50–250 MB），并可通过
navigator.storage.estimate()获取更稳定估算； - 临时存入内存 Map：适用于页面生命周期内有效的小状态（如表单草稿），避免数据丢失；
- 拆分存储：对大对象做分片（如每片 ≤ 100 KB），配合 key 命名规则（
data_123_part0）； - 启用持久化权限：
navigator.storage.persist()可提升部分浏览器的配额稳定性，但需用户授权。
安全清理要精准，避免误删核心数据
调用 clear() 会一并清除登录态、token、主题偏好等关键字段，风险极高。应按策略逐项清理：
- 只操作明确标记的非核心 key，如
cache_、draft_、search_； - 读取 value 后尝试
JSON.parse()，检查是否存在expiresAt或createdAt字段，优先剔除过期项； - 对解析失败的 value 视为损坏数据，可安全移除；
- 清理后建议校验关键字段（如
auth_token）是否仍存在，防止影响核心功能。
