IndexedDB 是浏览器中功能最强大的客户端数据库，但它的异步特性让很多开发者又爱又恨。
IndexedDB 与 localStorage 的对比：谁更适合你的项目？
很多开发者刚接触前端存储时,都会纠结选 IndexedDB 还是 localStorage，我的经验是，两者各有适用场景，但核心差异在于数据规模和查询复杂度。
- 存储容量：localStorage 通常限制在 5MB 左右，而 IndexedDB 没有硬性上限，只受磁盘空间和浏览器配额影响，据统计，大部分浏览器允许每个域名使用几百 MB 空间。
- 数据类型：localStorage 只支持字符串，存储对象需要序列化，IndexedDB 直接支持对象、数组、二进制数据，省去手动转换的麻烦。
- 查询方式：localStorage 只有键值对查询，无法按条件筛选，IndexedDB 支持索引、游标和范围查询，适合复杂检索需求。
- 异步机制：localStorage 是同步操作，容易阻塞主线程，IndexedDB 完全异步，基于事件或 Promise，不会拖慢页面响应。
从实际项目来看,如果需要存储用户偏好等简单配置，localStorage 足够，但面对离线地图数据、用户操作日志、富文本编辑器内容等场景，IndexedDB 才是可靠选择，它的学习成本主要体现在异步 API 的理解上，但一旦上手，就能发挥巨大价值。
存储容量与浏览器配额
IndexedDB 的存储空间并非无限，浏览器会为每个域名设置配额，Chrome 在桌面端允许使用最多 60% 的磁盘空间，但移动端浏览器限制更严格，国内移动端浏览器如 UC、QQ 浏览器，对 IndexedDB 的支持已相当完善，但配额可能低于桌面端。
性能差异的直观感受
在简单键值对读写上,localStorage 由于同步操作，单次写入更快，但批量操作或复杂查询时，IndexedDB 的优势明显，同时插入 1000 条记录，IndexedDB 通过事务批量提交，速度远快于 localStorage 的循环写入。
IndexedDB 使用场景分析：从离线存储到大数据管理
IndexedDB 的适用场景非常广泛，我总结了几类典型情况，帮助判断是否该采用。
- 离线应用：PWA 应用需要离线缓存数据，IndexedDB 可以存储完整的离线数据，与 Service Worker 配合，实现无网络时的完整功能，一个在线文档编辑器，离线时将编辑内容保存到 IndexedDB，联网后自动同步。
- 用户数据持久化：对于需要长期保存的用户设置、操作历史、草稿等，IndexedDB 比 localStorage 更可靠，它不会因为清除浏览器缓存而丢失，除非用户主动删除。
- 大数据量缓存：经常从服务器加载大量数据（如地理信息系统的地图瓦片、电商商品列表）时，缓存到 IndexedDB 可以减少网络请求，提升加载速度，近年来的实践中，很多大型单页应用采用这种方式优化首屏性能。
- 复杂查询需求：当需要按多个条件筛选数据时，IndexedDB 的索引机制效率极高，一个聊天应用需要按时间、发送者、消息类型查询历史消息，IndexedDB 可以轻松实现。
离线应用场景详解
以移动端 Web 应用为例，网络不稳定时，用户希望应用仍能正常使用，IndexedDB 可以存储核心数据，配合 Service Worker 缓存静态资源，实现完整的离线体验，行业共识认为，这是未来 Web 应用发展的方向之一。
大数据量缓存实践
在数据量较大的场景,如地图应用，瓦片数据可能达到几百 MB，IndexedDB 的存储上限完全满足需求，且通过索引可以快速定位指定区域的瓦片，避免遍历所有数据，我建议在创建对象存储时，为常用查询字段建立索引，可以显著提升查询速度。
IndexedDB 性能优化技巧：如何提升数据库操作速度？
性能优化是开发者最常问的问题之一,IndexedDB 的操作速度直接关系到用户体验，以下是我积累的几个优化点。
- 合理使用索引
：索引能加速查询，但每增加一个索引，写入操作的开销就会增加，只对频繁查询的字段建立索引，避免冗余，对于唯一值字段，设置 unique 属性可以同时保证数据一致性。
- 批量操作事务：多条写操作尽量放在同一个事务中，事务提交时批量写入，减少 I/O 次数，事务范围保持最小，避免长时间占用导致锁表，影响其他操作。
- 使用自动递增键：让主键自动递增，可以避免在插入前查询最大键值，简化逻辑并提升写入性能。
- 读写分离：读取操作使用只读事务，避免与写事务冲突，提高并发能力，在需要频繁读取的场景，考虑使用对象存储的缓存机制。
事务优化具体做法
打开数据库后,事务默认是自动提交的，如果需要多条操作，手动创建事务并显式提交，可以控制写入节奏，一次插入 1000 条数据，分成 10 个事务，每个事务 100 条，既能保证性能，又不会长时间占用数据库连接。
索引优化注意事项
创建索引时,如果字段值较长，索引本身也会占用空间，对于字符串字段，可以指定索引的 keyPath 选择子字段，或者使用自动生成的 ID 作为主键，避免索引过大，业内专家指出，索引设计是 IndexedDB 性能优化的核心，需要根据实际查询模式调整。
IndexedDB 数据库操作实战：一步步教你创建和查询
下面通过具体步骤演示 IndexedDB 的基本操作，从创建数据库到查询数据。
创建数据库并设计对象存储
- 打开数据库：
var request = indexedDB.open('myDatabase', 1); - 版本号升级时触发
onupgradeneeded事件，在此创建对象存储和索引。 - 创建一个名为
users的对象存储，主键为id，并为email字段创建唯一索引。
添加数据到对象存储
- 在
onsuccess回调中获取数据库实例。 - 创建一个读写事务,指定对象存储名称和操作模式。
- 调用
objectStore.add()或objectStore.put()方法添加数据。 - 数据可以是 JavaScript 对象，直接存储，无需序列化。
查询数据：使用索引按条件查找
- 创建一个只读事务,获取对象存储。
- 通过
store.index('email')获取索引对象。 - 使用
index.get('example@test.com')获取对应记录。 - 结果通过事件回调返回,异步处理结果。
更新和删除数据
- 更新数据：使用
put()方法，如果主键存在则更新，不存在则新增。 - 删除数据：使用
delete()方法，传入主键值。 - 大型操作建议放在事务中,确保数据一致性。
这些步骤涵盖了 IndexedDB 的日常操作，理解异步流程后，你会发现它并不复杂，对于更复杂的查询，如游标遍历、范围查询，可以查看官方文档，但核心原理一致。
IndexedDB 常见问题解答
Q1: IndexedDB 存储空间有限制吗？
A1: IndexedDB 没有固定的存储上限，实际可用空间取决于磁盘大小和浏览器策略，通常每个域名可以有几百 MB 甚至更多，但移动端浏览器可能限制更严格，用户可以通过浏览器设置查看和管理配额。
Q2: IndexedDB 数据会被清除吗？
A2: 用户清除浏览器缓存、卸载应用或使用清理工具时，IndexedDB 数据可能被删除，浏览器在磁盘空间不足时也可能自动清理长时间未使用的数据，但不会主动删除活跃数据。
Q3: IndexedDB 与 WebSQL 有什么区别？
A3: WebSQL 是已被废弃的标准，而 IndexedDB 是 W3C 官方推荐的客户端数据库方案，IndexedDB 基于对象存储，支持索引和事务，WebSQL 基于 SQL 语法，但已不再更新，当前所有主流浏览器都支持 IndexedDB，WebSQL 只在部分旧浏览器中可用。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/557617.html
