localstorage适用于小数据、简单结构、只读或极少更新场景，而indexeddb适合结构化、多字段、需查询修改及离线的复杂数据；误用会导致性能下降或维护困难。
Web Storage（主要是 localStorage）和 IndexedDB 不是“选一个就行”的关系，而是分工明确的两种工具。选错，轻则性能拖垮页面，重则数据逻辑难以维护。
小数据、简单结构、只读或极少更新 → 用 localStorage
- 存的是字符串，所有对象都得
JSON.stringify()和JSON.parse()，嵌套深或含函数、日期、Blob 时容易出错 - 容量通常 5–10MB，但实际可用空间因浏览器而异，超限会静默失败或抛
QuotaExceededError - 所有操作同步执行：写入 1MB 数据可能卡住主线程几百毫秒，用户点击无响应
- 查询靠遍历：比如查“所有 status 为 active 的用户”，必须把全部数据 load 进内存再
.filter()，10 万条记录就明显卡顿
结构化、多字段、要查、要改、要离线 → 用 IndexedDB
- 原生支持 JavaScript 对象、ArrayBuffer、Blob，存取不用序列化
- 异步 API，不阻塞渲染和交互；支持事务（ACID），并发写入更安全
- 可建多个 objectStore（类似表），每个可设 keyPath 和多个索引（如按
email、createdAt、status分别建索引） - 查询高效：用游标 + 索引，查某时间范围内的日志，耗时稳定在几十毫秒，和总数据量无关
- 容量大得多：现代浏览器通常允许占用磁盘空间的 50%，可通过
navigator.storage.estimate()动态获取
常见误用场景与建议
把用户草稿、表单中间状态、历史记录全塞 localStorage？
→ 数据一多（比如 500 条带富文本的草稿），每次打开页面就要 parse 几 MB 字符串，启动变慢；搜索、排序、分页都得手动实现，代码越来越重。换成 IndexedDB 后，加个lastModified索引，查最新 20 条只要一条游标查询。为兼容 IE11 而放弃 IndexedDB？
→ IE11 支持 IndexedDB 1.0（基础功能完整），真正不支持的是旧版 Safari（iOS idb 这类轻量封装，能抹平大部分兼容差异，比手写兼容代码更可靠。想用 localStorage 存 token 或主题偏好，又怕 XSS 泄露？
→ 这恰恰是它最合适的场景：数据量小、结构扁平、无需查询。配合httpOnlyCookie 存敏感凭证，localStorage 只放非敏感 UI 状态（如theme: 'dark'、sidebarCollapsed: false），风险可控。项目初期用 localStorage，后期数据变复杂了怎么办？
→ 别硬撑。设计迁移路径：首次加载时检测是否存在旧 localStorage 数据；有则批量导入 IndexedDB，导入完成后清空 localStorage。用户无感，代码渐进升级。
不复杂但容易忽略
