終於來到系列文的最後一天。這篇文章想做兩件事：
第一，帶大家實際鑽進 oven-sh/bun 的原始碼庫，
看看這個「號稱最快的 JavaScript 執行環境」在架構上到底是怎麼組織的；
第二，回顧這 30 天寫下來的一些心得，以及整理值得繼續深挖的參考資源。
當然我不大可能帶大家把整個源碼在這一章節讀完，
所以這篇主要是以組織還有導讀方向為主
打開 oven-sh/bun 的 repo，頂層大致長這樣（節錄重點目錄）：
bun/
├── src/ # 核心原始碼（含 Rust 呼叫進入點與尚未遷移的部分）
├── packages/ # Cargo workspace 內的 Rust crates + npm 相關套件
├── docs/ # 官方文件原始 Markdown
├── test/ # 龐大的測試套件（含 Node.js 相容性測試）
├── bench/ # 效能基準測試
├── patches/ # 對第三方依賴（如 WebKit）的 patch
├── scripts/ # 建置與開發腳本
├── completions/ # Shell 自動完成腳本
├── Cargo.toml # Rust workspace 進入點
├── Cargo.lock
├── CLAUDE.md # 給 AI coding agent 看的專案說明（很值得一讀！）
└── AGENTS.md
根據 DeepWiki 上針對 Bun 專案整理的架構文件，Bun 目前的核心邏輯以 Rust 為主力，並搭配其他語言各司其職：
Rust：整個 repo 是一個包含約 200 個 crates 的 Cargo workspace（根目錄的 Cargo.toml）,
承擔了絕大部分的核心邏輯——事件迴圈、模組解析、bundler、package manager 等主要模組都在這裡
要理解 Bun 目前怎麼運作，Cargo workspace 是最該優先掌握的部分。
Zig：仍保留在部分執行期（runtime）邏輯中，
這是 Bun 從一開始就採用的語言，
原因是它能直接呼叫 C ABI、沒有隱藏的執行期開銷，
很適合寫底層系統程式，目前與 Rust 部分並存。
**C++**專門處理與 JavaScriptCore（JSC） 的綁定層 :
Bun 選擇 JSC 而不是 V8 作為底層 JS 引擎，是它與 Node.js（V8）、Deno（V8）最大的技術差異之一，
這也是為什麼啟動速度和記憶體佔用會有明顯落差。
TypeScript / JavaScript：用來實作內建模組，
例如 node:fs、node:http 等 Node.js 相容層的部分邏輯，以及部分建置腳本。
Bun 甚至維護了自己 fork 過的 WebKit（oven-sh/webkit）
因為他們對 JSC 做了客製化 patch，
這也解釋了為什麼從源碼編譯 Bun 需要先編譯 JavaScriptCore、再編譯 C++ binding、最後才連結出 bun 執行檔——這個流程在 LICENSE.md 和 contributing 文件中都有提到。
Bun 官方定位自己是「all-in-one toolkit」，核心賣點是四合一：
這四塊功能在源碼中大致對應到（依 DeepWiki 整理的分區）：
Bun.serve）、HTTP Client / fetch、WebSocket、子行程管理、Socket 網路層、Streams API值得一提的是，Bun 的 JS transpiler、CSS lexer、以及 Node.js 模組解析器，
其源碼其實是 esbuild（Evan Wallace 的知名專案）的移植版本——這在官方 LICENSE.md
中有明確標注。如果你熟悉 esbuild 的內部設計，讀這部分 Bun 源碼時會有很強的既視感。
如果你也想像我這樣讀讀源碼，以下是我覺得比較不會迷路的順序：
先讀 README.md + CLAUDE.md + AGENTS.md：建立整體地圖，不要一頭栽進 src/。
看 Cargo.toml（workspace 根目錄）：了解目前有哪些 Rust crate、彼此的依賴關係，
這是目前最活躍、也最能反映核心邏輯的部分。
挑一個你熟悉的功能切入，例如：
Bun.serve，就去找 HTTP Server 相關模組搭配 DeepWiki 上的 Bun 專案文件：這是一個把整個 repo 建成可搜尋 wiki 的第三方工具，對於快速定位「這個功能大概在哪裡實作」非常有幫助，可以省下不少用 grep 亂找的時間。
實際跑一次 canary build：官方提供 bun upgrade --canary，
可以直接用到 main 分支最新的建置版本，搭配原始碼一起看，比較容易理解「這段程式碼實際上做了什麼」。
寫到系列最後一篇，想留幾點比較主觀的心得：
寫 30 天文章我個人覺得蠻累的，基本上每個資料還有請教 AI 的部分我都完整在本地以及雲端跑過驗證，
當然也有我個人加料的部分像是 Day25 把我自己所學也加入整合
有時候一度想要放棄，因為希望把文章品質維持其實在平日有工作的狀態下，非常折磨，
何況最近小弟公司的系統要配合更版加上準備日後議程以及 side project 等多重壓力下，
我已經竭盡所能把 bun 的完整系列生了出來
給後續想繼續深入的人，這裡整理一份延伸閱讀清單：
小弟我在一開始使用 bun 的時候是在 bun beta 版的時候，那時候我嘗試在跑我的前端項目，
後來導入公司，但那時候踩到雷，因為那時候還不夠穩定用 docker 起起來時有爆掉過，一度把打包專案改回 nodejs
直到 1.0 之後才比較穩定，且那時候出了 window 版本
那時候我就有念頭想說可以出個 bun 的系列集，不過有趣的是隨後竟然 bun 與 Anthropic 合體了😂
雖然我也是可以分享一些踩雷過程，但那些都已經在過去式了，在現今 bun 版本如此穩定的狀態下，那可能都是過時的資訊了
所以我再三思考，應該不會分享那些，
在主題的選取上我有一度遇到瓶頸，會猶豫是要講到 bun 的應用還是 bun 的分析，且深淺都要思考，所以盡可能把一個藍圖
弄出來，如果講得太深，反而沒辦法滿足所有人，我盡可能把每個部分由淺入深的提及，在深度的部分仍有保留，但也不至於
新手望塵莫及，但也不至於把文章弄得太淺，讓人認為我在水鐵人賽，所有部分我都盡可能驗證過，隨著深度增加，
我所需要的驗證時間，有成倍加長，不敢說自己文筆很好，但我盡可能讓 bun 每個直得摸的部分都沾過一輪，
如果讀者細心跟著我的步調沾過，應該沒有 bun 會難倒你的
另外，如果有從 day1 一路到現在一定會覺得我是不是少講許多厲害的東西，那是因為我需要考量到文章可讀性，
萬一再往下講，可能太深入，所以最後索性留下一點懸念，畢竟有些東西是有興趣的人也可以通曉，我僅留下來引路即可
也謝謝讀者耐心看完我 30 天的 bun 主題
iThome鐵人賽
看影片追技術