如果這幾年寫 JavaScript／TypeScript，你大概已經歷過這種痛苦：一個新專案要裝 npm 或 pnpm、加上 tsc 或 tsx 處理型別、再配 webpack 或 vite 打包、jest 或 vitest 跑測試、dotenv 讀環境變數——光是「讓工具鏈跑起來」就吃掉半天。
Bun 就是針對這一切而生的。而 2025 年底的一則消息，讓它從「很快的新玩具」正式變成「值得認真評估的基礎設施」：Anthropic 宣布收購 Bun。
一、Bun 是什麼？一個二進位檔就是一整條工具鏈
Bun 是由 Jarred Sumner 於 2021 年創立、以 Zig／Rust 撰寫的 JavaScript／TypeScript 執行環境。它最關鍵的技術選擇是：不採用 Node.js 與 Deno 使用的 Google V8 引擎，而是用 Apple Safari 的 JavaScriptCore（JSC），主打極致的啟動速度與低記憶體佔用。
但它真正的殺手鐧不是「快」，而是把整條工具鏈收進一個執行檔：
| 元件 | 指令 | 取代了什麼 |
|---|---|---|
| Runtime | bun run app.ts | node、ts-node、tsx |
| 套件管理器 | bun install | npm、yarn、pnpm |
| 打包器 | bun build | webpack、vite、esbuild |
| 測試框架 | bun test | jest、vitest |
| 開發伺服器 | bun run --hot | nodemon + HMR 設定 |
不只如此，它還內建了一堆「電池」：Bun.SQL（原生 Postgres／MySQL／SQLite 客戶端）、Bun.redis、Bun.s3、Bun.serve（高效能 HTTP 伺服器）、Bun.cron()（定時任務）、Bun.WebView（無頭瀏覽器），甚至自動載入 .env——這意味著你可以直接卸載 dotenv、nodemon、ts-node 一整排套件。
它到底解決了 Node.js 的哪些歷史包袱？
- 工具鏈碎裂：從 6 個工具變 1 個，設定檔數量直接砍半
- TypeScript 支援笨重：Node 迄今只支援受限的「型別剝離」（type stripping），Bun 支援全語法 TS（含 enums、decorators、namespaces），零設定直接跑
- CJS／ESM 割裂：Bun 原生深度相容兩者，同一個檔案可混用
import與require——這對搬遷老專案是巨大解脫 node_modules安裝極慢：見下方實測數據
二、為什麼是現在？Anthropic 收購與 Rust 重寫
2025 年 12 月，Anthropic 正式宣布收購 Bun（與 Claude Code 達到 10 億美元營收里程碑的公告同時發布）。這則消息的意義有三層：
- Bun 成為 Claude Code 的核心執行環境：Anthropic 將它定位為 Claude Code、Claude Agent SDK 與未來 AI 編程工具的底層基礎設施
- 棄坑風險（Abandonment Risk）大幅降低：對企業採用者而言，「這專案會不會沒人維護」的最大疑慮被頂級 AI 公司接手解決
- 維持 100% 開源與 MIT 授權（創辦人 Jarred Sumner 明確承諾）
更戲劇性的是 2026 年的技術演進：5 月至 8 月間，Bun 底層從 Zig 大規模重寫為 Rust，提升了記憶體安全性並修正了大量底層缺陷。截至 2026 年 9 月，最新穩定版為 Bun v1.4.2。
版本功能速覽
| 版本 | 重點新增 |
|---|---|
| 1.2 | Bun.SQL（Postgres）、Bun.s3、純文字 bun.lock |
| 1.3 | Bun.SQL 擴展至 MySQL／SQLite、Bun.redis、零設定 Dev Server + HMR、Node 測試相容率破 90% |
| 1.4 | Bun.WebView、Bun.Image、Bun.markdown、Bun.cron()、熱安裝再快 7 倍、原生支援 Windows ARM64 |
三、實測效能：什麼時候真的快？什麼時候差距消失？
網路上充斥「Bun 快 10 倍」的說法，但實際數據要看情境：
| 評測維度 | Bun（JSC） | Node.js（V8） |
|---|---|---|
| HTTP 吞吐（原生／Hono） | ~220,000–240,000 req/s | ~85,000 req/s |
| HTTP 吞吐（同一份 Express 程式碼） | ~52,000 req/s | ~13,000–14,000 req/s |
| 真實業務（短網址服務 + DB） | ~12,400 req/s | ~12,000 req/s（差距縮到 3%） |
| Monorepo 冷安裝（1,847 個依賴） | 47 秒 | 28 分鐘（npm） |
| AWS Lambda 冷啟動 | 156–290 ms | 245–940 ms |
| CPU 密集（排序 10 萬筆） | 1,700 ms | 3,400 ms |
| 記憶體佔用（Next.js App） | 380 MB | 512 MB |
⚠️ 最誠實的一行是第三列：在「真實業務 + 資料庫查詢」的場景下，Bun 與 Node.js 的差距只剩 3%——因為瓶頸已經轉移到資料庫與 I/O，不是執行引擎。
換句話說：Bun 的優勢在「啟動速度、安裝速度、工具鏈整合」與「高併發純運算」，不在「把慢查詢變快」。
四、安裝
macOS / Linux / WSL
curl -fsSL https://bun.sh/install | bash
Windows 原生（自 Bun 1.1 起完整支援，不需 WSL2）
powershell -c "irm bun.sh/install.ps1 | iex"
Docker（示範用官方映像）
FROM oven/bun:1.4-alpine
WORKDIR /app
COPY package.json bun.lock ./
RUN bun install --frozen-lockfile
COPY . .
EXPOSE 3000
CMD ["bun", "run", "index.ts"]
若你正在建立容器化環境，可搭配本站〈Docker 完整教學 2026〉一起看。
驗證安裝：
bun --version # 應顯示 1.4.x
五、核心指令速查
bun init # 建立新專案（產生 package.json + tsconfig + index.ts）
bun install # 安裝依賴（取代 npm install）
bun add hono # 安裝套件（取代 npm install hono）
bun run dev # 執行 package.json 的 script
bun run --hot index.ts # 內建熱重載，取代 nodemon
bun build ./index.ts --outdir ./dist # 打包
bun test # 內建測試（相容 Jest 語法）
bunx create-next-app my-app # 取代 npx
一個最小 HTTP 伺服器，不用任何框架：
// index.ts
const server = Bun.serve({
port: 3000,
fetch(req) {
return new Response("Hello from Bun!");
},
});
console.log(`Listening on http://localhost:${server.port}`);
六、從 Node.js 遷移：步驟與四大踩坑
遷移四步驟
- 清掉舊的：刪除
node_modules與package-lock.json，執行bun install產生bun.lock - 換掉指令：
node→bun、nodemon→bun run --hot、jest/vitest→bun test - 移除冗餘套件：
dotenv（Bun 自動載入.env）、ts-node、tsx、nodemon都可卸載 - 影子部署：先跑
bun test驗證，生產環境可用bun build --target node產出 Node 相容格式漸進過渡
🚧 四大踩坑（實測最常撞到的）
| 踩坑 | 症狀 | 解法 |
|---|---|---|
| C++ Native Addons | bcrypt、canvas、better-sqlite3 二進位不相容 | 換純 JS 版或原生模組：bcrypt → bcryptjs 或 Bun.password；better-sqlite3 → bun:sqlite |
ESM 下的 __dirname | 找不到路徑 | 改用 import.meta.url + fileURLToPath（Node／Bun 都相容） |
複雜的 jest.mock() | Mock 失敗（相容率約 85%） | 暫時保留 Vitest／Jest 跑測試 |
| 安全模型差異 | 沒有沙盒 | Bun 採 Full-trust 模式；需零信任隔離請用 Deno 或 Node 的 --permission |
七、生產環境：誰在用？該上線嗎？
目前公開的重量級採用者：
- Anthropic：Claude Code 與 Claude Agent SDK 的核心執行環境
- Midjourney：全站技術棧（伺服器路由、執行環境、前端打包、即時生成預覽）已全面遷移至 Bun，由極少數工程師支撐百萬級用戶
- Vercel：Vercel Functions 提供 Bun Runtime 原生支援
穩定度現況：在 1.2→1.4 連續迭代與 Rust 重寫後，Node.js API 相容率已達 90%–95%+，打包與測試模組已達生產級。
風險最低的策略是「混合模式」：
開發環境、CI 測試與打包用 Bun（吃極速開發的紅利）→ 生產環境仍部署到 Node.js。
八、什麼時候該用 Bun？什麼時候不該？
✅ 建議採用
- 全新 TypeScript 專案（Greenfield）：零設定、免編譯直接跑
- 想優化 CI/CD：安裝與測試時間可縮短 60%–80%
- Serverless／Edge 函數：冷啟動快 35%–69%
- 高併發 API 微服務（搭配 Hono、Elysia）：高吞吐 + 省 25%–40% 記憶體
- 想簡化工具鏈：不想再維護一堆設定檔
❌ 建議暫緩
- 高度依賴 C++ Native Addons 的老專案（
canvas、node-gyp等無法替換者） - 大型企業 Legacy 專案：重構成本高，Node.js LTS 已很穩
- 要求嚴格零信任沙盒的場景：選 Deno 或 Node 的
--permission - 特定舊版 APM 監控探針：部分 Datadog／New Relic Agent 深度綁定 Node 內部 Hook
結語：Bun 的真正價值不是「快」
Bun 常被當成「更快的 Node.js」來討論，但它的核心價值其實是把碎裂的 JavaScript 工具鏈重新收攏成一個二進位檔——而 Anthropic 的收購與 Rust 重寫，讓它從「週末玩具」變成「可以放進生產環境」的選項。
對開發者最務實的建議是：新專案直接用 Bun 開局，舊專案先用 Bun 跑安裝與測試。光是這兩件事，就能無痛拿回每天被工具鏈吃掉的一小時。
資料來源：Anthropic 官方公告（2025-12-03 收購 Bun）、Bun 官方部落格、Bun v1.4 發布說明、Wikipedia、DEV Community／Strapi／Aunimeda 2026 效能實測、SegmentFault 遷移實戰、ExplainThis 等，查證於 2026-09。
📌 延伸閱讀：本站〈Redis 完整教學 2026〉與〈PostgreSQL 完整教學 2026〉——Bun 內建
Bun.redis／Bun.SQL可直接串接這兩套資料庫。