indexeddb 与 web storage 是面向不同需求的本地存储机制，非升级替代关系：web storage 仅支持字符串键值对，适合简单状态存储；indexeddb 是异步结构化数据库，支持复杂查询、二进制数据及大容量缓存。
IndexedDB 和 Web Storage（包括 localStorage 和 sessionStorage）不是“升级替代关系”，而是面向不同需求设计的两种本地存储机制。选错方案，轻则性能拖累、查询困难，重则数据撑爆限制或丢失关键结构信息。
数据模型与操作方式根本不同
Web Storage 是纯键值对字符串存储：所有存进去的东西都得先 JSON.stringify()，读出来再 JSON.parse()；它没有“字段”“索引”“事务”的概念，只有 setItem/getItem/removeItem 这三个基础操作。
IndexedDB 是一个客户端数据库：支持对象、数组、Blob、ArrayBuffer 直接存取；可建多个 objectStore（类似表），每个能定义主键和多个索引；所有操作基于异步事务，支持游标遍历、范围查询、条件筛选。
- localStorage 存用户主题色？适合。存 500 条带时间戳的聊天记录并按日期查？不适合。
- IndexedDB 存离线新闻列表+图片 Blob？适合。只存一个登录 token？大材小用。
容量和实际可用空间差异显著
localStorage 容量通常为 5–10MB，且是硬性限制——超出会直接抛出 QuotaExceededError，没有任何缓冲或提示机制。
IndexedDB 理论上限高得多：现代浏览器普遍允许占用硬盘空间的 50%，实测常达数百 MB 甚至 GB 级；可通过 navigator.storage.estimate() 动态获取当前剩余配额，便于做容量预判和清理策略。
- 若应用需缓存离线地图瓦片、音频片段或用户上传的文档草稿，localStorage 很快见顶。
- IndexedDB 虽无固定上限，但也要注意：单次写入过大（如 >10MB 的 Blob）可能触发内存压力，建议分块处理。
适用场景不能只看“数据多不多”
真正决定选型的，是你是否需要结构化操作能力：
- 只需保存开关状态、深色模式偏好、短期 token → localStorage 足够，代码简洁，兼容性好。
- 要按时间范围查日志、按标签过滤笔记、支持离线编辑并同步冲突 → 必须用 IndexedDB，否则每次查询都要全量加载 + JS 遍历，卡顿明显。
- 涉及二进制文件（如截图、录音、PDF 缓存）、频繁增删改查、或多表关联逻辑 → Web Storage 无法支撑，IndexedDB 是唯一可行选项。
性能表现随数据规模剧烈分化
小数据时 localStorage 更快（写入 1KB 记录仅约 0.5ms）；但数据量上升后，它的同步阻塞特性成为瓶颈：
- 写入 1MB（约 1000 条记录）：localStorage 平均耗时 1250ms，界面完全卡死；IndexedDB 仅 320ms，且不阻塞 UI。
- 条件查询 100 条匹配项：localStorage 需遍历全部、手动 filter；IndexedDB 借助索引 + 游标，15ms 内完成。
- 注意：IndexedDB 初次打开数据库、创建 objectStore 或索引会有微小延迟，但后续读写稳定高效。
