Bun：把 JavaScript 執行時、套件管理器、測試和打包合在一起

Sun, 17 May 2026 17:42:25 +0800

Bun 是 oven-sh 開源的 JavaScript / TypeScript 一體化工具鏈。

它不是只想做一個更快的 Node.js 替代品，而是把執行時、套件管理器、腳本執行器、測試執行器和打包器都放進同一個 bun 命令裡。對前端和 Node.js 開發者來說，Bun 的吸引力在於：少裝一堆工具，少等一堆安裝和建置流程，很多常見任務可以直接用一個命令完成。

專案地址：https://github.com/oven-sh/bun

先說結論

Bun 最適合想簡化 JavaScript 工具鏈的人。

它能做這些事：

執行 JavaScript、TypeScript、JSX 和 TSX。
作為 Node.js 相容執行時。
替代 npm / yarn / pnpm 做套件管理。
執行 package.json 裡的 scripts。
執行測試。
打包前端或後端程式碼。
用 bunx 執行 npm 套件裡的命令。
提供 Bun.serve、bun:sqlite、Bun.sql、Bun.redis、Bun.s3 等內建 API。

它最明顯的價值是開發體驗：安裝依賴快、啟動快、命令統一、TypeScript 和 JSX 開箱即用。

但 Bun 也不是所有專案都應該立刻切換。大型 Node.js 專案、依賴大量原生擴充的專案、生產穩定性要求極高的服務，仍然需要逐項驗證相容性、建置行為、測試行為和部署方式。

Bun 是什麼

按照官方 README 的描述，Bun 是一個面向 JavaScript 和 TypeScript 應用的一體化工具包。它以單一可執行檔 bun 發布。

它的核心是 Bun runtime：一個快速 JavaScript 執行時，目標是作為 Node.js 的 drop-in replacement。Bun 使用 Zig 編寫，底層基於 JavaScriptCore，重點優化啟動時間和記憶體占用。

這意味著你可以直接執行：

`1`	`bun run index.tsx`

TypeScript 和 JSX 不需要額外設定就能跑。

同一個 bun 命令還包含：

test runner
script runner
Node.js 相容套件管理器
bundler
package runner

常見命令包括：

bun test
bun run start
bun install <pkg>
bunx cowsay 'Hello, world!'

過去一個專案裡可能同時出現 node、npm、pnpm、tsx、jest、vitest、webpack、esbuild、ts-node 等工具。Bun 的路線是盡量把高頻路徑收進一個工具裡。

安裝方式

Bun 支援 Linux、macOS 和 Windows，覆蓋 x64 與 arm64。

官方推薦安裝腳本：

`1`	`curl -fsSL https://bun.com/install \| bash`

Windows：

`1`	`powershell -c "irm bun.sh/install.ps1 \| iex"`

也可以透過 npm 安裝：

`1`	`npm install -g bun`

macOS Homebrew：

1
2

brew tap oven-sh/bun
brew install bun

Docker：

1
2

docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

Linux 使用者要注意核心版本。README 提到強烈建議 Linux kernel 5.6 或更高，最低要求是 5.1。

升級到最新版：

`1`	`bun upgrade`

升級到 canary：

`1`	`bun upgrade --canary`

生產環境一般不建議直接用 canary，除非你是在驗證新特性或排查特定 bug。

為什麼 Bun 會快

Bun 的「快」主要來自幾個層面。

第一，執行時啟動快。很多 CLI 工具和開發腳本的瓶頸不是長期 CPU 運算，而是程序啟動、模組載入、TypeScript 轉譯和依賴解析。Bun 針對這些路徑做了很多優化。

第二，套件管理快。bun install 的目標是替代 npm / yarn / pnpm 的依賴安裝流程。它使用全域快取和自己的 lockfile，安裝大量依賴時通常能明顯減少等待。

第三，TypeScript / JSX 開箱即用。很多專案只是想執行一個 .ts 或 .tsx 腳本，傳統 Node.js 工具鏈需要額外加 tsx、ts-node、Babel 或建置步驟。Bun 可以直接跑，減少了膠水工具。

第四，內建工具減少程序和設定切換。測試、腳本、打包、執行都在同一個工具裡，很多場景不用再在多個 CLI 之間切換。

但要注意，「Bun 很快」不等於每個專案都一定更快。真實效果取決於依賴類型、腳本邏輯、測試框架、建置設定、Node.js API 使用情況和 CI 快取策略。

套件管理：替代 npm / yarn / pnpm

Bun 可以直接安裝依賴：

`1`	`bun install`

新增依賴：

`1`	`bun add react`

新增開發依賴：

`1`	`bun add -d typescript`

移除依賴：

`1`	`bun remove react`

查看依賴原因：

`1`	`bun why react`

安全檢查：

`1`	`bun audit`

如果你從 npm 或 pnpm 遷移，重點要看：

bun.lock 是否進入版本控制。
CI 是否使用 bun install --frozen-lockfile。
私有 registry 和 .npmrc 是否相容。
workspace 行為是否符合預期。
lifecycle scripts 是否會帶來安全風險。
原本依賴 pnpm 特性的 monorepo 是否能平順遷移。

小專案可以直接試。大型 monorepo 不建議一次性全切，可以先在單個 package 或 CI 的非關鍵任務裡試。

執行腳本和 TypeScript

Bun 可以執行 package.json 裡的腳本：

`1`	`bun run start`

也可以直接執行檔案：

1
2

bun run index.ts
bun run index.tsx

這對工具腳本很方便，例如：

scripts/build.ts
scripts/seed.ts
scripts/migrate.ts
scripts/check.ts

如果用 Node.js，通常要處理 TypeScript loader 或預編譯問題。Bun 的直接執行能力可以讓這些腳本更輕。

不過，如果腳本依賴 Node.js 特定行為，尤其是 loader、ESM/CJS 邊界、原生模組、child process、檔案監聽和某些邊緣 API，仍然要測試。

測試執行器

Bun 內建測試執行器：

`1`	`bun test`

它適合想減少 Jest / Vitest 設定的小專案，也適合把一些單元測試、工具測試、庫測試遷移到更輕的執行方式。

遷移測試時重點關注：

expect 行為差異。
mock API 差異。
snapshot 行為。
DOM 測試環境。
測試發現規則。
覆蓋率輸出。
CI reporter 支援。

如果專案已經深度依賴 Jest 生態，例如大量自訂 matcher、複雜 mock、jsdom、babel-jest、ts-jest，遷移就不要太急。可以先讓新模組用 bun test，舊測試繼續保留原框架。

打包和建置

Bun 也提供 bundler，常見用法是：

`1`	`bun build ./src/index.ts --outdir ./dist`

它可以用於前端包、後端腳本、CLI 工具和庫建置。Bun 文件還覆蓋 loaders、plugins、macros、CSS、HTML、HMR、minifier、single-file executable 等方向。

適合優先嘗試的場景：

小型前端工具。
Node.js CLI。
內部腳本。
單檔服務。
不依賴複雜 webpack loader 的專案。

謹慎遷移的場景：

複雜 webpack 外掛鏈。
大量 Vite 外掛。
深度依賴 Babel 轉換。
特殊 CSS / asset pipeline。
微前端和模組聯邦。
對建置產物 hash、chunk、相容性要求很細的專案。

Bun bundler 很有吸引力，但建置工具遷移的風險通常比套件管理更高，最好單獨驗證。

執行 HTTP 服務

Bun 提供 Bun.serve 來寫 HTTP 服務：

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun")
  },
})

這對小型 API、內部服務、Webhook receiver、邊緣風格服務很方便。Bun 還提供 WebSockets、Workers、Streams、SQLite、PostgreSQL、Redis、S3、TCP/UDP sockets 等 API。

如果你已有 Express、Fastify、NestJS、Next.js、Hono、Elysia 等框架，也可以先看它們在 Bun 上的相容程度，不必為了用 Bun 就重寫服務。

更現實的路徑是：

先用 Bun 做開發腳本和套件管理。
再用 Bun 跑測試。
最後評估是否把執行時切到 Bun。

執行時遷移最需要謹慎，因為它直接影響生產服務行為。

和 Node.js 的關係

Bun 的目標之一是作為 Node.js 的 drop-in replacement，但「相容」不是「完全等同」。

Node.js 生態已經累積很多年，很多套件依賴細微行為：

CJS / ESM 互操作。
Node 內建模組。
原生擴充。
npm lifecycle scripts。
檔案系統邊緣行為。
stream 和 Buffer 細節。
worker / child_process。
除錯和 profiling。

Bun 在相容性上進步很快，但生產遷移仍要以測試結果為準。

比較穩妥的判斷方式：

你的測試能否在 Bun 下通過。
關鍵依賴是否支援 Bun。
建置產物是否一致。
CI 和本地表現是否一致。
線上執行是否有監控和回滾。
Docker 映像和部署腳本是否穩定。

如果只是替換套件管理器，風險較低；如果替換生產執行時，風險高很多。

適合哪些專案

Bun 很適合這些場景：

新的 JavaScript / TypeScript 小專案。
內部工具和腳本。
CLI 專案。
需要快速安裝依賴的 CI。
希望減少工具鏈複雜度的前端專案。
對啟動速度敏感的腳本和服務。
想用 TypeScript 開箱即跑的開發者。

暫時要謹慎的場景：

超大型 monorepo。
深度綁定 pnpm workspace 行為的專案。
依賴大量 Node.js 原生擴充的服務。
建置鏈路高度客製的前端工程。
對生產執行時一致性要求極高的後端。
依賴 Jest 複雜生態的測試套件。

一個保守但實用的策略是：先把 Bun 當作開發工具，而不是馬上替代全部生產執行時。

遷移建議

如果想在現有專案試 Bun，可以按這個順序：

在本地安裝 Bun。
執行 bun install，觀察依賴安裝結果。
提交或暫存 bun.lock，避免和舊 lockfile 混用造成混亂。
嘗試 bun run <script> 跑常用腳本。
用 bun test 遷移少量測試。
在 CI 加一個非阻塞 Bun job。
確認沒有相容問題後，再考慮替換主安裝流程。
最後再評估生產執行時是否切換。

對團隊專案，最好保留回滾路徑：

遷移前保留原 npm / pnpm / yarn 流程。
CI 裡同時跑一段時間。
不要在同一次改動裡同時換執行時、套件管理器、測試框架和打包器。
把遷移拆成小步驟，每一步都有可驗證收益。

這樣做雖然慢一點，但不容易把問題混在一起。

常見命令速查

安裝：

`1`	`curl -fsSL https://bun.com/install \| bash`

升級：

`1`	`bun upgrade`

安裝依賴：

`1`	`bun install`

新增依賴：

`1`	`bun add lodash`

執行腳本：

`1`	`bun run dev`

直接執行 TypeScript：

`1`	`bun run scripts/build.ts`

測試：

`1`	`bun test`

打包：

`1`	`bun build ./src/index.ts --outdir ./dist`

執行套件命令：

`1`	`bunx cowsay 'Hello, world!'`

總結

Bun 的價值不只是「比 Node.js 快」。更重要的是，它把 JavaScript / TypeScript 開發裡一堆分散工具收進一個 bun 命令：執行時、套件管理器、腳本執行器、測試執行器和打包器。

對新專案和內部工具來說，這種一體化體驗很舒服：安裝快、啟動快、設定少，TypeScript 和 JSX 也能直接跑。對已有大型專案來說，Bun 更適合先從低風險環節切入，例如套件安裝、腳本和部分測試，再逐步驗證建置和執行時。

如果你經常被 Node.js 工具鏈裡的安裝速度、設定碎片和測試啟動時間折磨，Bun 值得認真試一下。但真正遷移生產服務時，還是要回到最樸素的工程判斷：測試能不能過、依賴是否相容、CI 是否穩定、線上有沒有回滾。

參考連結：

JavaScript on KnightLi的博客