为什么 SQLite 至今还在用 C 写？
大家好，这里是架构资源栈！点击上方关注，添加“星标”，一起学习大厂前沿架构！
关注、发送C1即可获取JetBrains全家桶激活工具和码！
每隔一段时间，总有人问 SQLite 的作者 Richard Hipp：
“都 2025 年了，为什么 SQLite 还在用 C 写？为什么不用 C++？不用 Rust？”
答案其实很简单：
因为 C 依然是最合适的语言。
SQLite 自 2000 年 5 月 29 日问世以来，就坚持用“老掉牙”的 C 实现。
25 年过去了，它仍然稳如老狗，不打算换语言。
一、C 依然是最好的选择
SQLite 团队列出了四个理由：性能、兼容性、依赖少、稳定性强。
听起来很教科书，但每一点都掷地有声。
🚀 1. 性能：快才是王道
SQLite 是一个被频繁调用的底层库，速度当然是首要指标。
C 被称为“可移植的汇编语言”，几乎贴着硬件写代码，但又能跨平台。
其他语言都在说自己“和 C 一样快”，
但从没人敢说“比 C 更快”。
SQLite 官方甚至还自豪地列了几个性能对比：
比文件系统还快 35%。这就不是吹牛，而是实打实的硬实力。
🌍 2. 兼容性：C 到哪都能跑
世界上几乎所有系统都能调用 C 写的库。
举个例子：
Android 用 Java 写 App，但可以直接调用 SQLite。
要是当初 SQLite 用 Java 写，那苹果的 Swift 和 Objective-C 就没法用了。
——iPhone 上就直接没 SQLite 这回事。
🧩 3. 依赖少：C 没有“家族负担”
SQLite 的最小构建只依赖几个 C 标准库函数：
memcmp()
memcpy()
memmove()
memset()
strcmp()
strlen()
strncmp()
就这些。
没有虚拟机，没有几百 MB 的 runtime。
别的“现代语言”，动辄几千个依赖包、几兆体积，SQLite 看了都摇头。
🧱 4. 稳定：C 老，但不变
C 的好处之一，就是——它太老了，以至于没人再折腾它。
SQLite 的作者就说：
写一个小巧、快速、稳定的数据库引擎已经够难了，
要是语言规范还一年一变，那真是噩梦。
所以，C 的“无聊”，恰恰是 SQLite 想要的“安稳”。
二、为什么不用面向对象语言？
有些人不理解：
“这么复杂的系统，怎么能不用面向对象？”
SQLite 的回答很“硬核”：
1️⃣ C 写的库谁都能用。
而 C++、Java 写的库通常只能被同语言调用。
你见过 Java 调用 C++ 库的痛苦吗？C 没这问题。
2️⃣ 面向对象是一种思想，不是语法糖。
你想面向对象？C 也能写，只不过语法朴素点。
3️⃣ 面向对象不总是最优解。
有时候，老老实实的过程式代码更易懂、更快、更稳定。
4️⃣ 当年 C++ 太混乱，Java 太稚嫩。
2000 年那会儿，C++ 编译器兼容性差，Java 还在学走路。
所以，选 C 是理性决定，不是情怀。
三、那为什么不换成 Rust 或 Go？
毕竟现在 Rust 这么火，Go 也很香。
很多人就问：
“SQLite 要不要重写一版 Rust 呀？更安全呀！”
官方的回答很冷静，也很现实：
1️⃣ SQLite 前十年它们都还没出生。
要重写？风险比收益大得多。
2️⃣ 安全语言插了太多“检查分支”。
为了验证数组越界之类的安全性，会导致机器码无法 100% 分支测试。
而 SQLite 的质量控制体系，非常依赖“分支全覆盖测试”。
3️⃣ Rust/Go 的 OOM 策略不同。
Rust/Go 通常会在内存不足时直接 abort。
SQLite 的设计是：即使 OOM，也要优雅恢复。
4️⃣ 语言太新，不够“无聊”。
是的，他们希望 Rust 变得更“老气横秋”，
再考虑用它。
四、如果哪天真的重写 SQLite……
那大概率也只可能是 Rust 版本。
但前提条件一长串：
- Rust 必须“变稳”，别再天天更新。
- Rust 必须能被所有语言调用。
- Rust 得能跑在各种嵌入式设备上。
- Rust 工具链要支持 100% 分支覆盖测试。
- Rust 要能优雅地处理内存不足。
- 性能不能掉速。
满足这些？
SQLite 作者说：“欢迎来聊，但别急。”
🧠 最后的思考
SQLite 的坚持，其实不是固执，而是工程哲学的体现：
技术可以流行，但基础设施必须稳定。
C 语言或许没有潮流光环，
但它让 SQLite 能在数十亿设备上无声运行、无惧时间。
正如官方那句 slogan：
Small. Fast. Reliable. Choose any three.
SQLite 选了三个，全都要。
喜欢就奖励一个“👍”和“在看”呗~
浙公网安备 33010602011771号