大家好，這裏是架構資源棧！點擊上方關注，添加“星標”，一起學習大廠前沿架構！
關注、發送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 選了三個，全都要。
喜歡就獎勵一個“👍”和“在看”唄~
