web storage（localstorage/sessionstorage）不推荐用于大规模结构化数据，因其同步阻塞、仅支持字符串、无索引与事务、序列化开销大、易导致ui卡顿；应优先选用indexeddb或cache api等进阶方案。
Web Storage（包括 localStorage 和 sessionStorage）在处理大规模结构化数据时，**存储效率偏低，不推荐直接使用**。它本质是同步、阻塞式、字符串键值对的简单存储机制，面对复杂或大量数据时会暴露明显瓶颈。
同步 I/O 严重拖慢主线程
每次 setItem 或 getItem 都触发磁盘读写，且必须等待完成才能继续执行 JS。当结构化数据体积增大（例如超过 1MB 的数组或嵌套对象），JSON 序列化/反序列化本身就会消耗数十毫秒——这会直接导致页面卡顿、响应延迟甚至无响应。
- 实测：存取一个含 1 万条字符串的数组，
JSON.stringify()+localStorage.setItem()常耗时 40–80ms - 高频操作（如实时保存编辑草稿）叠加后极易引发肉眼可见的 UI 冻结
- 无法异步化，也不能中断或取消，浏览器主线程被完全占用
单条容量与整体配额限制明显
主流浏览器为 localStorage 分配约 5–10MB 总空间，但实际可用远低于此——因浏览器预留元数据、压缩开销及安全策略限制。更重要的是，它不支持分片或索引：
- 无法按字段查询，只能全量读取后在内存中过滤（比如“查 status 为 pending 的订单”需 load 全部再
.filter()） - 更新部分字段必须重写整个字符串值，造成冗余序列化和写入放大
- 没有事务支持，多处并发写入可能覆盖彼此（如两个标签页同时 save）
结构化能力缺失，维护成本高
Web Storage 仅接受字符串值，所有对象、日期、Map、Set 等都需手动序列化。长期运行后容易出现：
- 类型丢失：
new Date()存成字符串，读取后需额外 parse；null和undefined都变成"null" - 版本错乱：字段结构调整（如从
{name, email}升级为{profile: {name, email}}）需自行实现迁移逻辑 - 调试困难：浏览器开发者工具中只显示原始 JSON 字符串，无法展开查看结构或搜索子字段
更合适的大规模结构化替代方案
若业务确需本地持久化大量结构化数据（如离线笔记、本地数据库、缓存 API 响应等），应优先考虑：
- IndexedDB：真正的客户端 NoSQL 数据库，支持索引、游标遍历、事务、异步读写，单库容量可达数百 MB 至 GB 级
- Cache API + Service Worker：适合结构化资源缓存（如 JSON API 响应），配合 Headers 和 Request/Response 对象，天然支持 HTTP 语义
- 内存缓存 + 按需落盘：高频访问数据保留在 JS 对象中，仅关键变更或退出前批量写入 localStorage，降低 I/O 频次
localStorage 更适合作为轻量级状态兜底——比如用户主题偏好、折叠面板开关、小表单草稿，而非数据主存储层。
