<!-- title: 信任无法编译：Rust重写的只是SQLite分身 -->
<!-- domain: programming -->
<!-- video: https://www.youtube.com/watch?v=Sntj4HmuykI -->

# 信任无法编译：Rust 重写的只是 SQLite 分身

## 导语：当"最被信任的代码"要换一副骨架

如果你的手机能说话，它大概会告诉你一个秘密：它身体里住着同一个数据库引擎——无论你用的是 Android 还是 iPhone，无论你打开的是 Chrome、Safari 还是 Firefox，无论你看的是本地通讯录还是离线地图。这个引擎叫 **SQLite**，地球上被部署得最多的数据库，没有之一。Fireship 在标题里给它一个更煽情的称谓："地球上最被信任的代码"（the most trusted code on Earth）。

而这期视频要讲的事，听起来像技术圈的"换心手术"：有人把这副运行了 25 年的 C 语言老骨架，用 **Rust** 从头重写了一遍，而且据称——"真的能跑"（it actually works）。产品叫 **Turso**（前身项目代号 Limbo）。

这件事值不值得你花十分钟看完？非常值得。但它真正的价值，不在于"Rust 又干翻了一个 C 项目"这种爽文叙事，而在于它戳中了软件工程里一个被长期误解的命题：**代码的"信任"到底从何而来——是语言给的，还是时间给的？** 理解了这一点，你就能看懂当下所有"用 Rust 重写 X"热潮里，哪些是真革命，哪些只是重新发明轮子。

## 视频背景卡片

| 项目 | 内容 |
|------|------|
| 视频标题 | The most trusted code on Earth is being rewritten in Rust |
| 频道 | Fireship（百万级订阅的开发者科普顶流） |
| 时长 | Fireship 代码解说标准长度（约 8–12 分钟） |
| 播放量 | 约 55 万次（截至 2026 年 7 月） |
| 发布时间 | 约 3 周前（2026 年 6 月中旬） |
| 核心主题 | SQLite 被 Rust 重写为 Turso，以及"信任能否被语言移植" |
| 视频原话锚点 | "SQLite, the world's most trusted code, just got rewritten in Rust... It's called Turso" |

## 一、先搞清楚：为什么 SQLite 配得上"最被信任"

视频一上来就把 SQLite 推上神坛，但很多人并不知道它为什么神。这部分是视频默认你已经懂、但其实值得补的背景。

SQLite 由 **D. Richard Hipp** 在 **2000 年 8 月** 发布，用 **C 语言**写成，授权方式极为特殊——不是 MIT、不是 GPL，而是**彻底的公有领域（Public Domain）**。这意味着任何人可以拿它做任何事，连署名都不强制。正是这个"零约束"的授权，让它能无障碍地钻进每一台设备：某百科明确记载，它是"部署最广泛的数据库引擎"，被主流浏览器、操作系统、手机和各类嵌入式系统普遍使用。

但"被用得多"只是结果，**真正让它"被信任"的，是它近乎病态的测试文化**。SQLite 的测试体系包含好几套互相独立的 harness：开源的 TCL 测试、专有的 C 语言测试套件 **TH3**、用来和其他 SQL 数据库交叉比对的 SQL Logic Tests，以及名为 **dbsqlfuzz** 的模糊测试引擎。社区里流传一句话——SQLite 的**测试代码量是源码的成百上千倍**，分支覆盖率（branch coverage）逼近 100%，还用上了航空级安全软件才讲究的 **MC/DC**（修改条件/判定覆盖）指标。换句话说，SQLite 是靠"用海量输入把每个分支都锤过一遍"换来的可靠，而不是靠语言本身。

**这点是全文的认知地基**：SQLite 的信任来自 25 年的反复蹂躏，而不是 C 这个语言。那么问题来了——换语言，能把这份信任一起搬走吗？

## 二、Turso/Limbo：用 Rust 重新实现一个 SQLite

视频的主角 Turso，在 GitHub 上的官方自述非常克制但又野心勃勃："**An in-process SQL database written in Rust, compatible with SQLite**"（一个用 Rust 编写、与 SQLite 兼容的进程内 SQL 数据库）。请注意这里的措辞——是 **compatible with**（兼容），不是 is、不是 replaces。这一个介词，藏着整件事的真相。

这个项目前身代号 **Limbo**，由数据库创业公司 **Turso** 主导，目标是"从零用 Rust 重写一个行为和 SQLite 一致的数据库"。它瞄准的兼容范围相当激进，包括三件事：**SQL 方言、磁盘文件格式、以及 C API**。也就是说，理想情况下，你原来调用 `sqlite3_prepare` 的代码，换成它的接口后能"几乎无感"地继续跑，连数据库文件都能直接打开。

从 Turso 公开的项目特性看，这个 Rust 版本不止是"翻译"，还顺手加了一批 SQLite 原生没有或不愿加的能力：基于 **MVCC** 的 `BEGIN CONCURRENT`（提升写并发）、**CDC（变更数据捕获）**、Linux 上的 **io_uring 异步 I/O**、多语言绑定（Go / JS / Java / .NET / Python / Rust / WebAssembly）、以及当下最热的**原生向量检索（vector search）**能力，实验性功能还包括静态加密、基于 **DBSP** 的增量计算、由 **tantivy** 驱动的全文检索。

但 README 也老老实实挂着一行警告：**This software is in BETA**（仍处 Beta，生产数据请谨慎并做好备份）。这行字，恰好是理解整件事的钥匙。

## 三、最关键的认知反转：重写换不来信任，信任无法编译

**这是我对这期视频最重要的延伸判断，也是视频用一句"it actually works"轻轻带过、却最该被深挖的地方。**

当一个项目说"我用 Rust 把 SQLite 重写了一遍"，外行听到的是"SQLite 升级了"，内行听到的是"**一个全新的、零岁的新代码库诞生了**"。它和那个被锤了 25 年的 SQLite，是两个完全不同的生命体——就像你和你的克隆体共享 DNA，却不可能共享你活过的每一天。

原因回到第一节：SQLite 的可靠不在 C，而在那套"成百上千倍于源码的测试"。Rust 的 borrow checker 能在编译期消灭一整类**内存安全 bug**（空指针、缓冲区溢出、use-after-free、数据竞争），这是 C 永远做不到的、货真价实的进步；但 Rust **消灭不了逻辑 bug**，更不可能凭空生成 SQLite 那 25 年积累下来的、对无数边界情形的精确处理。SQL 方言里有海量的历史包袱和诡异行为（比如 SQLite 那著名的**动态类型**——你可以往声明为 INTEGER 的列里塞字符串），要"兼容"就意味着把这些怪癖一个一个复刻出来，差一个字节都可能让依赖它的应用炸掉。

所以更准确的说法是：**Rust 重写的不是 SQLite 本体，而是 SQLite 的一个"分身"**。这个分身继承了"形"（接口、格式、方言），却还没继承"魂"（那座由时间浇筑的信任之塔）。它要从零开始，重新一寸一寸地攒回自己的信誉。这也解释了为什么 README 要强调 Beta——"能跑"和"可托付"之间，隔着的是无数个凌晨的生产事故。

## 四、那为什么还要重写？真动机是"控制权"和"新需求"

如果信任搬不过来，Turso 为什么还非要做？因为对一个商业公司来说，**站在别人的代码上，永远长不出自己想要的翅膀**。

SQLite 由 Hipp 个人维护、走的是极度保守的路线——稳定压倒一切，新功能能不加就不加。这对全世界的存量用户是恩赐，但对一家想做"边缘数据库"生意的创业公司却是枷锁。Turso 想要的东西，SQLite 给不了：

- **边缘/无服务器架构**：要在全球节点上跑、要支持"每个租户一个数据库"的超大规模细分（Turso 的核心商业模式），需要一个能被深度改造、易于嵌入的内核；
- **AI 时代的向量检索**：大模型应用的 RAG、语义搜索需要原生向量能力，而 SQLite 主线不会集成；
- **现代 I/O 与并发**：`io_uring`、MVCC 写并发这些性能特性，在保守的 C 代码库里推进极慢；
- **可维护的掌控权**：C 代码库改起来如履薄冰，Rust 的类型系统和所有权模型让团队敢大刀阔斧地迭代。

换句话说，**这次重写的第一驱动力其实是"商业可控性 + 新功能"，内存安全只是顺带的、却最容易被拿来宣传的红利**。把"用 Rust 重写"单纯理解成"为了安全"，是只看到了故事的封面。

## 五、把它放进更大的浪潮：内存安全正在重塑基础设施

视频虽聚焦 SQLite，但它其实是一股更大浪潮的一朵浪花。理解这股浪潮，你才能判断这类重写的长期价值。

长期以来，**70% 这个数字**反复出现在各大厂商的安全报告里：微软 MSRC 的分析指出，其历年修复的 CVE 中约七成是**内存安全漏洞**；Google 的 Chrome 团队给出几乎相同的比例——约七成严重安全缺陷与内存安全相关。这些 bug 正是 C/C++ 的"原生病"，也正是 Rust 在编译期就能治好的病。

于是从政策端到产业端形成合流：美国国家安全局（NSA）在 2022 年的公告中明确推荐使用**内存安全语言**（Rust、Go、C#、Java、Swift 等）；白宫国家网络主任办公室（ONCD）2024 年的报告《Back to the Building Blocks》呼吁行业向内存安全语言迁移；CISA 的"Secure by Design"持续施压。产业端则是一长串"用 Rust 重写关键基础设施"的清单：从 **sudo**（sudo-rs，把那道通往 root 的大门换成内存安全版）、到 **OpenSSL/TLS 栈**（Rustls）、再到 **Linux 内核**接受 Rust 驱动、**Windows** 用 Rust 重写核心组件。

SQLite→Turso 正是这条线上的又一站。区别在于：sudo、OpenSSL 这类重写，更多是"换语言保功能"；而 Turso 是"换语言 + 加功能 + 抢控制权"，野心更大，要验证的也更多。

## 六、别被"It actually works"骗了：兼容性才是真正的深渊

视频最抓人的那句"it actually works"（它真的能用），是典型的 Fireship 式钩子。但作为开发者，你得知道"能用"在这个语境下有多廉价、又有多昂贵。

廉价在于：能跑通 `SELECT * FROM users` 这种基础语句，对于任何像样的 SQL 引擎都不是难事，Demo 效果拉满很容易。昂贵在于：**真正的兼容性，是行为级（behavioral）的，不是语法级的**。SQLite 的稳定承诺里有一条著名的——它从 2004 年起保证**跨版本数据库文件格式稳定**，2020 年起保证**API 稳定**。任何一个用了 SQLite 十年的 App，今天还能打开十年前的数据库文件。Turso 若要真正"兼容"，就必须复刻这层承诺，包括那些没人愿意碰的历史怪行为、错误码的精确返回顺序、并发冲突时的具体语义……这是一个没有终点的逆向工程。

更现实的风险是**生态分裂**：当一个数据库对外宣称"兼容 SQLite"，用户会默认它能无缝替换；可一旦在某个边界行为上不一致，踩坑的排查成本极高，因为所有人都会默认"SQLite 不会这样"。这就是为什么许多"X 的 Rust 重写"项目最终止步于"能 demo"——不是写不出来，而是**追平一个被时间验证过的系统，比从零造一个更难**。

## 知识结构图

```mermaid
flowchart TD
    A["SQLite（本体）<br/>D. Richard Hipp / 2000 / C 语言 / 公有领域<br/>部署最广的数据库引擎"]

    A --> T1["信任来源：时间 + 测试<br/>TH3 / SQL Logic Test / dbsqlfuzz<br/>测试代码量 ≫ 源码 · 分支覆盖≈100% · MC/DC"]

    A -->|"被重写（compatible with，非 replace）"| B["Turso Database（前身 Limbo）<br/>用 Rust 从零重写 · 仍处 BETA"]

    B --> F1["语言红利（编译期）<br/>内存安全：消灭空指针/溢出/UAF/数据竞争"]
    B --> F2["新增能力<br/>MVCC写并发 · CDC · io_uring<br/>原生向量检索 · 多语言绑定"]
    B --> F3["商业动机<br/>边缘/无服务器 · 每租户一库<br/>控制权 · 快速迭代"]

    B --> G["未继承：信任<br/>0 岁 · 必须重新积累<br/>行为级兼容是深渊"]

    T1 -.->|"Rust 借鉴检查器给不了"| G

    style A fill:#e8f0fe,stroke:#1a73e8
    style B fill:#fef7e0,stroke:#f9ab00
    style G fill:#fce8e6,stroke:#d93025
    style T1 fill:#e6f4ea,stroke:#188038
```

## 实战启示：普通开发者该怎么用这件事

**1. 选型时，把"语言"和"成熟度"分开打分。** 看到"用 Rust 重写"别自动加分。Rust 保证的是内存安全这一个维度；而你在生产里真正踩的坑，往往来自并发语义、边界行为、文件格式兼容这些"时间问题"。给候选数据库一个二维评分卡：横轴是语言安全性，纵轴是"被实战验证的年头"——SQLite 在后者上是满分，Turso 在后者上是起步分。

**2. 区分两类重写，决定要不要上车。** 第一类是"功能平替型"（如 sudo-rs），目标是更安全的等价物，适合在安全敏感场景逐步替换；第二类是"功能扩展型"（如 Turso），它本质是新物种，**为边缘部署、向量检索、多租户而生**。如果你做的是 AI 应用的本地向量库、或无服务器场景的 per-tenant 数据库，Turso 这类正是为你设计的；如果你只是想要一个稳如磐石的单机本地库，继续用 SQLite——它的 25 年信任是 Turso 短期内给不了的。

**3. 用"兼容性承诺"反向拷问任何新引擎。** 问三个问题：它的文件格式跨版本稳不稳定？它的 SQL 方言和目标系统行为级一致还是有已知差异？它的错误处理路径是否一一对应？能正面回答这三点的"重写"，才值得你在非 Demo 场景认真评估。

**4. 从 SQLite 的测试文化里偷一招。** 无论你写什么语言，SQLite 给的方法论是普世的——**多套独立测试 harness 交叉验证、用模糊测试持续锤炼、追求高分支覆盖**。Rust 让你免于一类 bug，但优秀的测试文化才能让你接近 SQLite 那种"被信任"。语言是地板，测试才是天花板。

## 延伸学习路径

1. **SQLite 官方文档：How SQLite Is Tested**（sqlite.org）——理解"信任"是怎么被测试工程浇筑出来的，看完你会对测试有全新认识。
2. **Turso / Limbo 的 GitHub 仓库与 COMPAT.md**（github.com/tursodatabase）——看一个 Rust 重写项目如何定义"兼容"，以及它坦承哪些还没追平。
3. **NSA《Software Memory Safety》与白宫 ONCD《Back to the Building Blocks》报告**——从政策视角理解"内存安全语言迁移"为何成为国家级议题。
4. **Matt Miller / MSRC 的《Trends, Challenge, and Shifts in Software Vulnerability Mitigation》**——"70% 漏洞是内存安全 bug"这个数字的原始出处，数据比口号更有说服力。
5. **Rust 官方《The Rust Programming Language》第 4 章（Ownership）**——亲手感受 borrow checker 如何在编译期消灭整类 bug，理解这场重写的底层红利从何而来。

## 一句话总结

> 一个用 Rust 重写的 SQLite，能拿到内存安全这张"出生证"，却拿不到那 25 年测试浇筑的"信任状"——重写换得来语言，换不来时间。

## 参考来源

1. [The most trusted code on Earth is being rewritten in Rust — Fireship](https://www.youtube.com/watch?v=Sntj4HmuykI) — 本期分析的核心视频，其描述明确点明"SQLite, the world's most trusted code, just got rewritten in Rust... It's called Turso"。
3. [Turso Database (formerly Limbo) — GitHub README](https://github.com/tursodatabase/turso) — 确认该项目"用 Rust 编写、与 SQLite 兼容"，并列出 MVCC、CDC、io_uring、向量检索等特性及 BETA 状态。
4. [How SQLite Is Tested — sqlite.org](https://www.sqlite.org/testing.html) — SQLite 官方对自身测试方法论的权威说明（高分支覆盖、MC/DC、模糊测试）。
5. [Back to the Building Blocks: A Path Toward Secure Software — ONCD (White House, 2024)](https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/memory-safe-roadmap/) — 推动向内存安全语言迁移的政策背景。

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
