web storage 无原生查询能力，仅支持全量遍历；indexeddb 支持索引+游标条件查询，可高效按字段筛选、范围查询、分页及事务操作。

Web Storage 没有原生查询能力，IndexedDB 支持索引+游标条件查询——这是两者在数据检索层面最本质的分水岭。

Web Storage 的“伪查询”：只能遍历，无法过滤

localStorage 和 sessionStorage 本质上是键值对字典，不提供任何内置索引或查询接口。想查出所有邮箱以 “@gmail.com” 结尾的用户？必须手动 读取全部数据、JSON.parse、逐条判断：

• 哪怕只存了 100 条记录，也要全部加载进内存再筛一遍
• 数据量超过几 MB 时，JSON.parse 可能触发主线程卡顿
• 无法利用字段做快速定位，比如按时间范围、状态、分类等筛选
• 没有事务保障，多步操作（如“查+改+删”）无法原子执行

IndexedDB 的真查询：索引驱动 + 游标遍历

IndexedDB 允许为任意字段建索引，并通过游标（cursor）实现高效、定向的数据访问：

• 建索引示例：store.createIndex('status', 'status')，后续可直接查 status: 'active'
• 支持范围查询：index.openCursor(IDBKeyRange.bound('2025-01', '2025-12'))
• 支持唯一约束（{unique: true}），避免重复写入
• 游标可正向/反向遍历，也可跳过前 N 条（skip）、限制条数（limit）
• 所有操作都在事务中进行，保证数据一致性

实际场景中的表现差异

假设一个待办应用存储 5000 条任务，含 title、status、dueDate、priority 字段：

• 用 Web Storage：每次筛选“高优先级+未完成”需加载全部 JSON，耗时约 80–120ms（含解析），且随数据增长线性变慢
• 用 IndexedDB：提前为 priority 和 status 建复合索引，相同查询平均耗时稳定在 3–8ms，与总量无关
• 若还需分页展示第 201–300 条，IndexedDB 可用游标 skip(200).limit(100) 直接命中；Web Storage 必须全量加载后 slice

什么时候该放弃“查”，转而换思路？

不是所有场景都需要复杂查询。如果只是偶尔按 key 精确读取（如 getItem('theme') 或 getItem('user_token')），Web Storage 更轻量、更直接。但只要出现以下任一需求，就该考虑 IndexedDB：

• 需要根据非主键字段查找（如按邮箱、时间、标签、状态）
• 数据条目超过几百条，且前端需频繁筛选/排序/分页
• 涉及二进制内容（图片 Blob、音频 ArrayBuffer）或嵌套对象结构
• 要求操作具备事务性（例如：更新用户信息 + 同步日志 + 修改配置，要么全成功，要么全回滚）