indexeddb在大容量存储场景下明显优于localstorage，因其对象存储模型、异步机制、更高配额（可达数gb）、索引查询能力及事务支持，而localstorage受限于字符串序列化、同步阻塞、5–10mb硬限制和无部分更新能力。
IndexedDB 在大容量存储场景下明显优于 localStorage，核心差异在于数据结构、存储机制和浏览器限制。
数据模型决定读写效率
localStorage 是纯键值对存储，所有数据都转为字符串序列化，读取时需整体解析；而 IndexedDB 是基于对象存储的异步数据库，支持索引、游标遍历和增量读取。当存储 10MB 以上 JSON 数据时，localStorage 的 getItem 可能触发主线程阻塞数百毫秒，IndexedDB 则通过事务分片和异步回调避免卡顿。
- localStorage 每次读写都加载/保存整个字符串，无部分更新能力
- IndexedDB 可按主键或索引精准查询，支持范围查询（IDBKeyRange）
- 对 50,000 条记录做条件筛选，IndexedDB 用索引查询通常在 20–80ms，localStorage 需全量 JSON.parse + 数组 filter，常超 500ms
容量限制与稳定性差异
localStorage 通常限制在 5–10MB（各浏览器不一），超出直接抛错；IndexedDB 默认配额更高（Chrome 约占用磁盘空间的 50%，上限可达数 GB），且会主动触发 storagequotaexceeded 事件提示，而非静默失败。
- localStorage 写入超限：静默失败或报
QuotaExceededError，无降级策略 - IndexedDB 支持事务回滚、批量写入（
add()/put()批处理）、以及clear()快速清空指定 objectStore - 实测在 200MB 数据集下，IndexedDB 分块导入耗时约 3–6 秒（含压缩），localStorage 无法完成同等操作
实际使用中的关键注意点
IndexedDB 性能优势需正确使用才能体现，错误模式反而比 localStorage 更慢。
- 避免在单个事务中写入过多记录——建议每事务 ≤ 500 条，防止长时间锁表
- 频繁读取小字段时，可建专用轻量索引（如只索引
status字段），减少数据载入量 - localStorage 适合存 token、用户偏好等 KB 级配置；IndexedDB 应用于离线缓存、日志队列、本地相册等 MB+ 场景
- 务必监听
onupgradeneeded正确建索引，否则查询退化为全表扫描
不复杂但容易忽略：大容量下，localStorage 是“能用但危险”，IndexedDB 是“要学但可靠”。选型不应只看 API 简洁度，而要看数据规模和访问模式。
