Node.js 核心團隊近期提出了一項重大提案，計畫在 runtime 中內建一個名為 node:vfs 的虛擬檔案系統模組。這項變動不僅僅是增加一個 API，更是對 Node.js 處理 I/O 方式的一次重要擴展。對於開發者來說，這將解決長期以來依賴實體磁碟 I/O 所導致的效能瓶頸與安全風險。
什麼是虛擬檔案系統 VFS
在傳統的開發模式中，當我們使用 fs 模組讀寫檔案時，作業系統會實際在硬碟上進行讀寫操作。而 VFS（Virtual File System）是一種抽象層，它允許程式在記憶體中模擬一套完整的檔案系統結構。簡單來說，它讓程式以為自己在讀寫硬碟上的檔案，但實際上所有資料都儲存在 RAM 中。
這項提案旨在提供一個與現有 fs API 完全相容的記憶體內實作，支援掛載點（Mount Points）、疊加模式（Overlay Mode）、符號連結（Symlinks）以及模組載入鉤子（Module Loading Hooks）。
為什麼我們需要 VFS
對於許多工程實務場景，實體磁碟 I/O 往往是效能的殺手或安全漏洞。VFS 主要能解決以下四個核心問題。
首先是 AI 生成程式碼的執行。目前的 AI Agent 在執行生成的程式碼時，通常需要將程式碼寫入臨時檔案、執行後再刪除。這種流程不僅緩慢且容易留下垃圾檔案。有了 VFS，AI 生成的代碼可以直接在記憶體中運行並被 import，流程更簡潔且快速。
其次是大幅提升測試效能。在大型專案中，若測試案例需要頻繁建立與讀取大量設定檔或暫存檔，磁碟 I/O 會導致測試時間大幅增加。根據社群回饋，部分專案在將 13,000 個測試從實體磁碟遷移至 VFS 後，執行時間從 40 分鐘縮短至 3 分鐘。
第三是單一可執行應用程式（SEA）的封裝。當我們將 Node.js 應用打包成單一執行檔時，內建的 VFS 可以讓應用程式在不解壓縮到臨時目錄的情況下，直接從記憶體讀取內嵌的資源檔案。
最後是多租戶平台的沙箱隔離（Sandboxing）。在雲端環境中執行第三方不可信的程式碼時，直接給予實體檔案系統權限極其危險。VFS 可以在記憶體中建立一個完全隔離的虛擬環境，確保程式碼無法觸及主機的真實檔案。
目前的實作進度與替代方案
雖然 node:vfs 尚未正式進入 Node.js 核心，但相關功能已經可以透過社群套件提前體驗。Platformatic 推出的 @platformatic/vfs 以及 Vercel 提供的 node-vfs-polyfill 均實作了相同的 API 規範。這意味著開發者現在可以先在 Node.js 22 以上版本中使用這些套件，未來待官方模組發布後，只需將 import 路徑更改為 node:vfs 即可完成遷移。
AI 生成代碼引發的爭議
這項提案在 GitHub 上引起熱議的原因，除了功能本身，更在於其開發過程。提案者 Matteo Collina 坦承，該 PR 中約 19,000 行的程式碼有大量部分是由 AI 工具 Claude Code 協助生成。
這在開源社群引發了關於核心基礎設施品質的辯論。反對者認為，Node.js 作為全球關鍵的基礎設施，不應容許 AI 生成的程式碼進入核心，因為這會增加審核壓力，且可能對開發者原創證明（DCO）造成法律或合規上的疑慮。而支持者則認為，只要架構設計正確且經過嚴格的人工審核，利用 AI 處理繁瑣的實作細節能大幅提升開發效率。
總結與展望
Node.js 技術指導委員會（TSC）將針對 AI 輔助貢獻的政策進行投票，這將決定 node:vfs 提案的最終命運。無論結果如何，VFS 的概念已經證明其在現代開發流程中，特別是在 AI Agent 與高效能測試場景下的巨大價值。目前 Deno 已經開始追蹤相關相容性，而 Bun 雖在實體 I/O 吞吐量領先，但尚未公布對應的 VFS 計劃。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。