web storage容量上限为5–10mb，是硬性边界而非弹性配额，超限即抛出quotaexceedederror；按utf-16字节计算，中文字符占2字节，json序列化开销计入总量；无自动清理、无索引查询、同步阻塞，单对象超2mb或需结构化操作时应转向indexeddb。
Web Storage 的容量上限（通常 5–10 MB）对大型数据缓存有实质性制约，不是“够用或不够用”的简单判断，而是直接决定能否采用该方案——超限即失败，且无渐进降级能力。
容量限制本质是硬性边界，不是弹性配额
浏览器对每个源（origin）分配的 localStorage/sessionStorage 空间是固定配额，Chrome 约 6.5 MB，Safari iOS 甚至仅 2.5 MB。这个数值按 UTF-16 字节计算：一个中文字符占 2 字节，JSON 序列化后的引号、空格、缩进全计入。存一个含 100 条商品信息的数组，看似不大，但 stringify 后可能轻松突破 4 MB。
- 调用
localStorage.setItem()超限时会抛出QuotaExceededError，JS 执行中断，不自动清理旧数据 - 无法通过
localStorage.length或遍历 key 判断剩余空间，必须主动估算或捕获异常 - 没有“写满警告”或“自动淘汰机制”，不像 HTTP 缓存可配置 LRU 或 max-age
大型缓存场景下易触发性能与可靠性问题
当尝试用 Web Storage 缓存图片 Base64、API 响应集合、离线文章全文等内容时，容量瓶颈会连带引发其他风险：
- 同步阻塞：大量数据读写会卡住主线程，页面响应变慢，尤其在低端设备上明显
-
序列化开销：每次存取都要
JSON.stringify()/JSON.parse()，对象越大耗时越长，且可能因循环引用直接报错 - 无索引查询：只能靠 key 精确匹配，无法按字段筛选或分页，查 1000 条记录中的某几条需全量读取再过滤
-
清理不可控：手动清空需遍历所有 key，大数据量下耗时严重；依赖命名前缀（如
cache:article:）管理，但无批量删除 API
什么情况下该果断放弃 Web Storage？
出现以下任一情况，说明已超出 Web Storage 的适用边界，应转向 IndexedDB 或服务端协调缓存：
- 单次缓存对象体积 > 2 MB（留足余量防编码膨胀）
- 需要按条件查询、分页、全文检索等结构化操作
- 缓存数据需长期保留且总量持续增长（如用户本地日志、历史文档）
- 多标签页协同编辑同一份缓存，或需监听数据变更事件（Web Storage 仅靠
storage事件通知，不支持细粒度监听）
小规模缓存仍可高效利用，关键在设计收敛
容量限制倒逼更严谨的数据治理习惯：
- 只存必要字段，避免缓存完整 API 响应，提取
{id, title, updatedAt}即可 - 用时间戳+版本号控制过期，例如
localStorage.setItem('config_v2_202606', JSON.stringify({...}))，旧版自动失效 - 优先用 sessionStorage 处理临时态数据（如多步表单），关闭即释放，不占用持久空间
- 敏感字段绝不落地，登录态 token 存内存变量，刷新后重新获取，比“加密存在 localStorage”更安全
不复杂但容易忽略：容量不是孤立指标，它和序列化成本、查询方式、生命周期管理交织在一起。选对工具的前提，是承认 Web Storage 的定位——它是轻量状态锚点，不是客户端数据库。
