為什麼 C 語言擁有最好的檔案 API？

背景

這篇文章探討了 C 語言在處理檔案存取時的獨特優勢，特別是透過記憶體映射（Memory Mapping, mmap）技術，讓開發者能像操作記憶體數據一樣直接處理大型檔案。作者認為，相較於現代語言普遍採用的序列化與解析模式，C 語言這種將檔案視為二進位格式並直接映射的方式，在處理超大型數據或記憶體受限的系統時，提供了更高效且簡潔的解決方案。

社群觀點

Hacker News 的討論首先針對「mmap 是否屬於 C 語言」展開了激烈的技術辯論。多位評論者指出，mmap 本質上是作業系統提供的系統調用（Syscall），屬於 POSIX 標準或特定平台（如 BSD）的特性，而非 C 語言本身的語法組成。雖然 C 語言因為是 Unix 系統的母語，往往能最先且最直接地調用這些底層接口，但這並不代表其他語言無法達成。例如 Python 的標準庫中就內建了 mmap 模組，而 C# 與 Java 也有對應的記憶體映射 API。評論者認為，作者將平台特性歸功於語言本身，在技術定義上略顯偏頗。

在實務應用層面，社群對 mmap 的評價褒貶不一。支持者認同其在處理隨機存取與大檔案時的便利性，但反對者則強調了其隱藏的複雜性與風險。最嚴重的問題在於錯誤處理，當使用 mmap 遇到磁碟故障、網路斷線或硬體拔除時，系統會拋出 SIGBUS 或 SIGSEGV 等訊號（Signal），這對大多數高階語言的開發者來說極難優雅地處理。相比之下，傳統的 read/write 雖然繁瑣，卻能透過回傳值提供清晰的錯誤訊息。此外，mmap 在處理 32 位元架構下的位址空間限制、快取一致性以及跨平台兼容性（如 Windows 與 POSIX 的差異）等方面，都存在不小的挑戰。

另一派觀點則從軟體架構的角度出發，認為作者對「檔案即數據庫」的想像過於理想化。有評論者指出，現代開發中之所以普遍使用 SQLite 或 LMDB，正是因為單純的檔案映射無法解決併發控制、索引優化與數據完整性等問題。雖然 C 語言提供了最原始的工具，但這並不等同於「最好的 API」。對於大多數應用場景而言，解析與序列化雖然有性能開銷，卻換取了數據的安全性與可移植性。部分資深開發者更直言，mmap 雖然簡單，但在現代高性能需求下，其效率已逐漸落後於 io_uring 等新興技術，且在處理不可信的外部數據時，直接映射二進位格式極易引發安全漏洞。

延伸閱讀

• SQLite 官方文件：探討為何在某些情境下 SQLite 比直接操作檔案系統更快。
• Simon Tatham 的 C 語言協程（Coroutines）介紹：關於如何在不依賴多執行緒的情況下實現高效異步 I/O。
• Ada 語言的 POSIX 綁定專案（Florist）：展示其他語言如何實現底層檔案接口。