web storage容量小（5–10mb）、同步阻塞、无索引查询，适合轻量状态；indexeddb容量大（gb级）、异步事务、支持索引与原生类型，适用于海量/二进制/条件查询场景。
数据容量与存储深度差异明显
Web Storage（localStorage 和 sessionStorage）本质是键值对字符串存储，单域容量通常为 5–10MB，实际可用受浏览器策略影响，比如 Safari 在无痕模式下可能压缩至 2MB。它不支持嵌套结构原生存储——哪怕存一个对象，也必须先 JSON.stringify()，读取时再 JSON.parse()，深层嵌套或大体积 JSON 容易触发序列化失败或内存抖动。
IndexedDB 是真正的客户端数据库，单库容量可达 数百MB甚至GB级（取决于设备磁盘空间和浏览器配额策略），能直接存 Object、Array、Date、Blob、File、TypedArray 等原生类型，无需序列化转换。它还支持分片写入、流式读取二进制数据，适合缓存离线视频片段、用户上传的图纸或本地生成的加密日志。
读写性能逻辑完全不同
Web Storage 是同步 API，操作瞬间返回，但会阻塞 JS 主线程。比如一次性遍历 localStorage 中 5000 条记录做筛选，页面会卡顿；大量连续 setItem 可能引发渲染延迟，尤其在低端安卓 WebView 中表现更明显。
IndexedDB 是异步 + 事务驱动，所有操作都基于 request → success/error 回调或 Promise 链。虽然单次读写有微小延迟，但它天然支持并发控制、游标遍历、索引查询和批量事务。例如：用游标按时间范围扫描 10 万条日志并聚合统计，耗时稳定可控；而同样操作在 localStorage 中需全量加载再 JS 过滤，内存占用高、CPU 峰值陡升。
- 高频小数据（如用户主题色、开关状态）→ Web Storage 更轻快
- 中等结构化数据（如表单草稿、多步骤流程状态）→ 可用 Web Storage，但建议加防抖和大小校验
- 海量/二进制/需条件查询的数据（如离线消息、用户画像特征向量、PWA 资源缓存）→ IndexedDB 是唯一合理选择
查询能力决定适用边界
Web Storage 没有索引、没有查询语法，只能靠 for...in 或 Object.keys() 遍历全部 key，再逐个 getItem() 解析内容匹配条件。相当于“把整个仓库搬出来翻箱倒柜”。
IndexedDB 支持在 objectStore 上创建多个索引（如 createIndex('byEmail', 'email') 或 createIndex('byTimeRange', ['createdAt', 'status'])），配合 openCursor() 或 getAll() 的 range 参数，可实现毫秒级范围查询、去重统计、分页加载。例如：查“过去7天未读消息”，只需一次 indexedDB 查询，而非加载全部消息再过滤。
错误处理与稳定性表现
Web Storage 在超出配额时抛出 QuotaExceededError，但不提供具体哪次操作越界、剩余多少空间等信息，错误恢复困难；且数据损坏后无法修复，只能整体清空。
IndexedDB 提供细粒度事务控制：transaction.onabort、request.onerror、db.onversionchange 等事件可精准定位问题环节。配合版本升级机制，还能安全迁移旧数据结构（如从 v1 用户表字段扩展到 v2 增加 avatar 字段）。它的设计目标就是长期、可靠、可演进的本地数据管理。
