QuickJS作者Fabrice Bellard在2024年3月發(fā)布了一個實驗項目：用C語言手寫JavaScript運行時，完整支持定時器、文件I/O和事件循環(huán)，總代碼量不到2000行。

對比Node.js依賴的V8引擎——僅核心代碼就超過100萬行——這個數(shù)字像是程序員界的"降維打擊"。但Bellard沒打算替代誰，他只是證明了一件事：JavaScript運行時可以很小，小到能塞進你的咖啡杯。

引擎和運行時，差了一個宇宙

很多開發(fā)者搞混這兩個概念。JavaScript引擎（如V8、JavaScriptCore）只干一件事：執(zhí)行JS代碼。它不知道文件是什么，沒聽說過HTTP，對定時器一臉茫然。

運行時（如Node.js、Deno、Bun）才是完整環(huán)境。它把引擎包進來，再塞入文件系統(tǒng)、網(wǎng)絡棧、事件循環(huán)——就像給裸機裝上操作系統(tǒng)。Bellard這次造的"andjs"，屬于后者。

他的目標很明確：console.log、process.uptime()、setTimeout/clearTimeout、fs.readFileSync/fs.readFile，外加事件循環(huán)和I/O線程池。沒有npm，沒有模塊系統(tǒng)，沒有HTTP服務器。夠用就行。

從空文件到能跑JS：200行C代碼

Bellard沒碰QuickJS自帶的qjs.c運行時，選擇從零開始。最小可運行版本只需要三樣東西：JSRuntime實例（引擎本體）、JSContext（執(zhí)行環(huán)境）、以及一個讀取-執(zhí)行-報錯的循環(huán)。

核心代碼精簡到讓人懷疑人生：創(chuàng)建運行時、創(chuàng)建上下文、運行文件、清理資源。

run_file函數(shù)更直白：讀文件、調(diào)用JS_Eval執(zhí)行、檢查異常、釋放內(nèi)存。沒有黑魔法。當代碼拋出錯誤時，它會原樣打印堆?！蚇ode.js報錯格式幾乎一致。

第一個能跑的版本已經(jīng)可以執(zhí)行throw new Error("test exception")，并在終端吐出完整的錯誤位置。但問題是：沒有console.log，成功的程序鴉雀無聲。

console.log：第一個"系統(tǒng)調(diào)用"

給JS環(huán)境添加全局函數(shù)，本質(zhì)上是C函數(shù)和JS的橋接。Bellard定義了一個js_print函數(shù)，接收JSContext和參數(shù)列表，把值轉(zhuǎn)成字符串，輸出到stdout。

注冊過程用到了QuickJS的C API：先創(chuàng)建JSValueCFunction，再用JS_SetPropertyStr綁定到globalThis.console對象。JS_CFUNC_DEF宏隱藏了類型轉(zhuǎn)換的臟活，讓C函數(shù)看起來像是原生的JS方法。

這里有個細節(jié)：console.log在JS里是變長參數(shù)，但C函數(shù)需要顯式處理argc/argv。Bellard的實現(xiàn)遍歷所有參數(shù)，用JS_ToCString轉(zhuǎn)字符串，空格分隔，最后換行。和瀏覽器行為一致，但代碼只有20行。

定時器：事件循環(huán)的入門考試

setTimeout是運行時的分水嶺。它強制你回答：回調(diào)存在哪？什么時候執(zhí)行？誰負責調(diào)度？

Bellard的方案很務實。定時器用鏈表存儲，每個節(jié)點記錄回調(diào)函數(shù)、延遲時間、是否重復（setInterval）。主循環(huán)檢查當前時間與觸發(fā)時間，到點就執(zhí)行。

但JS_Eval是同步的，執(zhí)行完就返回。定時器的回調(diào)怎么辦？Bellard在main函數(shù)末尾加了一個事件循環(huán)：while (has_pending_jobs) { execute_pending_jobs(); }。QuickJS內(nèi)部維護了微任務隊列，但宏任務（定時器）需要運行時自己實現(xiàn)。

更棘手的是異步I/O。readFileSync會阻塞線程，這在2000行的玩具里可以接受。但真正的運行時不能讓文件讀取卡住整個事件循環(huán)——Bellard引入了worker pool。

線程池：用C寫Promise的底層

fs.readFile返回Promise，但C沒有Promise。Bellard的解法是把I/O扔給后臺線程，主線程繼續(xù)跑事件循環(huán)，等數(shù)據(jù)準備好了再回調(diào)。

具體實現(xiàn)：提交任務到隊列，worker線程取走、執(zhí)行read()、把結(jié)果塞回主線程的待處理列表。主循環(huán)每次迭代檢查這個列表，把完成的I/O包裝成Promise的resolve。

這里用到了QuickJS的JS_EnqueueJob機制，讓C層能向JS層投遞任務。整個流程和libuv（Node.js的I/O庫）原理相同，但代碼量差了三個數(shù)量級。

2000行能教給我們什么

Bellard這個項目沒有發(fā)布版本號，沒有路線圖，Git倉庫甚至沒開issue。它更像一份"參考答案"：如果你被Node.js的復雜度嚇退，這里有一條最小可行路徑。

但別誤會，這不是生產(chǎn)級代碼。沒有內(nèi)存泄漏檢查，沒有安全沙箱，沒有模塊加載器。它回答的是"能不能"，而非"應不應該"。

有趣的是，QuickJS本身的設(shè)計哲學在這里得到了延續(xù)。Bellard在2019年發(fā)布QuickJS時，主打的就是"小巧、可嵌入、啟動快"。這次的手寫運行時，算是把"小"字寫到了極致。

Node.js用V8是因為要兼容Chrome的JS語義，要追求極致性能。但如果你只需要跑一些腳本，處理文件和定時器，2000行C代碼真的夠用了——這個事實本身，可能比代碼更有沖擊力。

項目最后能運行的示例程序，讀起來和Node.js幾乎無異：啟動計時、延遲執(zhí)行、同步讀文件、異步讀文件、打印結(jié)果。區(qū)別只在于，你知道這背后沒有百萬行代碼的支撐，只有一個程序員三天的周末。

如果所有JavaScript運行時都能被壓縮到這種程度，我們還需要Docker鏡像里那個500MB的node:alpine嗎？