应优先选用indexeddb而非localstorage。因大数据量下localstorage同步写入致页面卡顿，而indexeddb异步事务保障ui响应；且仅indexeddb支持字段索引实现高效查询。
选型不能只看“谁快”，而要看“在什么条件下怎么用才不拖垮页面”。大数据量下，localStorage 表面简单，实则暗藏卡顿风险；IndexedDB 看似复杂，但结构和异步机制让它真正扛得住压力。关键不是比单次操作毫秒数，而是看数据规模上升后，UI是否还跟手、查询是否还精准、出错后能否回滚。
看数据量增长时的写入稳定性
localStorage 每次 setItem 都同步序列化+写磁盘，主线程直接冻结。存 5000 条记录（每条约 2KB）可能耗时 800ms 以上，用户会明显感到页面卡死。IndexedDB 把写入放进事务队列，后台线程处理，同样数据通常 100–300ms 完成，界面始终响应。
- 数据量 ≤ 100 条、总大小
- 数据量 ≥ 1000 条、或单次写入 > 500KB：必须用 IndexedDB，否则体验断崖式下降
- 需要批量导入导出（如离线日志、本地备份）：IndexedDB 支持分块事务，localStorage 无此能力
看查询方式是否依赖字段筛选
localStorage 只能靠 key 直接取值。想查“昨天创建的所有订单”？得把整个 JSON 字符串 parse 出来，再遍历过滤——数据越多越慢。IndexedDB 可为 dateCreated、status 等字段建索引，用 IDBKeyRange 一键定位，10 万条中查某天数据通常
- 只需按固定 key 读配置（如 theme、lang）：localStorage 完全胜任
- 需按时间、状态、关键词等条件组合查询：IndexedDB 是唯一可行方案
- 有分页、排序、模糊搜索需求：IndexedDB 游标 + 索引可原生支持，localStorage 必须全量加载再前端计算
看数据可靠性与并发场景
localStorage 没事务、没版本、没并发控制。两个 Tab 同时写同一 key，后写者直接覆盖前者；写到一半报错，中间状态无法回滚。IndexedDB 支持 ACID 事务，add/put/clear 可包进一个事务，失败自动回退，适合表单草稿、多端协同编辑等场景。
- 单页静态配置、token 缓存：localStorage 足够安全
- 用户频繁编辑的富文本草稿、离线提交的订单队列：必须用 IndexedDB 保障数据一致
- 多个 Tab 或 Web Worker 共享数据：IndexedDB 支持跨上下文打开同一数据库，storage 事件在 localStorage 中延迟不可控
看容量边界与降级策略
localStorage 通常限 5–10MB（Safari 移动端仅 2.5MB），超限直接抛 QuotaExceededError，无提示、无回调、无法预判。IndexedDB 容量更大（Chrome 默认可达磁盘空间 60%），且可通过 navigator.storage.estimate() 主动获取可用配额，配合 onversionchange 和 storagequotaexceeded 事件做平滑降级。
- 预估总数据量长期
- 需缓存地图瓦片、音频片段、用户本地相册等二进制内容：IndexedDB 可存 Blob / ArrayBuffer，localStorage 不支持
- 上线前要做容量兜底：IndexedDB 能提前预警并触发清理逻辑，localStorage 只能在报错后被动处理
