写了十年的 IndexedDB 今天被 Chrome 从 LevelDB 换成了 SQLite——三引擎终于统一了

Chrome 的 IndexedDB 底层今天正在经历一次彻底重建：用了十几年的 LevelDB + 平面文件组合，正在被 SQLite 全面替换。Firefox 和 Safari 早就用上了 SQLite，只有 Chrome 一直拖着——这不是技术选型问题，而是 LevelDB 已经没人维护，bug 一堆，数据丢失的坑无数开发者踩过。

Chrome 为什么要换掉 LevelDB

Chromium 团队在 2026 年 4 月的官方公告里说得很直白：LevelDB 不是没人维护，是它本身就不够格当 IndexedDB 的引擎。LevelDB 不支持完整的 ACID 事务，不支持 SQL 查询，数据损坏全靠应用层自己兜。官方文档里有一句话特别扎眼——「Many sophisticated web apps report high rates of missing or corrupt data」，复杂 Web 应用的数据丢失率长期居高不下，根子就在这里。

具体来说，LevelDB 在 Chromium 里的实现是一套混合架构：元数据用 LevelDB，blob 数据存平面文件，两边的一致性依赖应用层保障。一旦进程异常退出，或者存储空间紧张，LevelDB 的 sst 文件和元数据之间就容易出现不一致，导致数据库损坏、打不开，或者数据莫名其妙消失。这种问题在 PWAMail、Calendar 这种重度依赖 IndexedDB 的应用里特别常见，开发者只能加一层备份逻辑，或者干脆不用 IndexedDB。

三阶段迁移，现在到哪一步了

这次重写不是一次完成的，Chrome 把它拆成了三步：

第一步（Chrome 144~148）：内存场景先行。先在无痕模式和内存型上下文里用 SQLite 跑起来，不碰磁盘数据，降低翻车影响面。这一步验证了 SQLite 后端的稳定性，也积累了线上数据。

第二步（Chrome 150 起）：新数据存储全面切换。从 Chrome 150 开始，用户第一次访问网站（或者清空站点数据后），新的 IndexedDB 数据直接写进 SQLite，不再经过 LevelDB。现有磁盘数据不受影响，仍然走老路径，等第三步再迁。

第三步（待执行）：存量数据迁移。等新数据存储稳定后，会提供工具把 LevelDB 格式的存量数据迁移到 SQLite，或者静默后台执行迁移。这一步风险最高，官方承诺会单独发 PSA 预警。

目前处于第二步，Chrome 150 是第一个全面落地的版本，覆盖桌面和 Android 双平台。

行为变更：transaction scheduling 的 edge case

这次重写不只换了引擎，还同步修了一个 transaction 调度上的跨浏览器行为差异。官方文档提到：新的 SQLite 后端在某个 transaction 调度场景下的行为与 Firefox/Safari 一致了，Chrome 原来的行为其实是 edge case，不符合 IndexedDB 规范定义。官方提供了 Demo 供开发者验证：https://evanstade.github.io/web-storage-demos/idb-txn-scopes

这个变更对大多数应用没影响，但如果你的应用重度依赖 IndexedDB transaction 的调度顺序，建议跑一下 Demo 确认。

开发者需要做什么

好消息是：Web API 完全没变，代码一行不用改。IndexedDB 的 API surface 保持不变，后端换成 SQLite 对应用层完全透明。

但有几件事值得提前确认：

第一，如果你的应用重度依赖 IndexedDB 且数据量较大，留意一下迁移窗口期的行为。Chrome 150 起新数据走 SQLite，但老数据还在 LevelDB，两套后端并行，期间如果清空站点数据会触发新后端。

第二，性能特性会变。官方明确说这次重写「to a lesser extent performance」——主要目标是可靠性提升，性能改善是附带的。但 SQLite 的事务模型比 LevelDB 健壮得多，在高并发写入场景下，LevelDB 的那些诡异 race condition 应该会少很多。

第三，Chrome 这次还提到一个新的 edge case 行为变更。如果你的应用里 IndexedDB transaction 的调度顺序很关键，跑一下官方 Demo（https://evanstade.github.io/web-storage-demos/idb-txn-scopes）确认一下行为是否一致。

下一步

去 https://chromestatus.com/feature/5161589557821440 订阅这个特性的进展，第三步迁移开始前 Chrome 会单独发 PSA。到时候如果涉及存量数据迁移，提前规划好清数据的时机。