Next.js Turbopack 完整教學：Rust 驅動的打包工具設定與效能優化指南

老實說，第一次聽到 Turbopack 的時候我是半信半疑的。又一個打包工具？Webpack 用得好好的幹嘛換？但當我實際在專案裡跑起來，看著 dev server 在毫秒級啟動完成，我整個人就回不去了。今天就來聊聊這個由 Rust 驅動的新一代打包工具，以及怎麼在你的 Next.js 專案裡設定它。

Turbopack 是什麼？為什麼用 Rust 寫？

Turbopack 是 Vercel 團隊開發的下一代 JavaScript/TypeScript 打包工具，也是 Webpack 創始人 Tobias Koppers 的新作品。它的核心完全用 Rust 撰寫，這不是為了趕流行，而是有非常實際的考量。

JavaScript 是單執行緒語言，而打包這件事天生就適合平行處理。Rust 提供了零成本抽象、記憶體安全以及原生多執行緒能力，這讓 Turbopack 可以充分利用多核 CPU 來加速打包流程。根據 Vercel 官方數據，在大型專案中 Turbopack 的冷啟動速度比 Webpack 快上數倍，Hot Module Replacement（HMR）更是快到幾乎感覺不到延遲。

另一個關鍵設計是增量運算引擎（Turbo Engine）。它會記住每個函式層級的運算結果，當你改了一個檔案，它只重新計算受影響的部分，而不是整個 dependency graph。這概念類似資料庫的 materialized view，非常聰明。

Turbopack vs Webpack：實際效能差異

數字會說話。以下是我在一個中型 Next.js 專案（約 200 個元件、30 個路由）上的實測結果：

最讓我驚豔的是 HMR 速度。改一行 CSS 幾乎是存檔的瞬間畫面就更新了，開發體驗提升非常有感。

如何啟用 Turbopack

好消息是，在 Next.js 15 中啟用 Turbopack 非常簡單。確保你的 Next.js 版本在 15 以上，然後修改你的開發指令：

# package.json
{
  "scripts": {
    "dev": "next dev --turbopack",
    "build": "next build",
    "start": "next start"
  }
}

就這樣，一個 flag 搞定。執行 npm run dev 後你應該會在終端機看到 Turbopack 的標誌，確認它已經在運作。

如果你是用 create-next-app 建立新專案，可以在建立時直接選擇啟用：

npx create-next-app@latest my-app --turbopack

如果你的專案正在使用 Next.js App Router，那 Turbopack 的整合會更加順暢，因為 App Router 和 Turbopack 是一起設計的。

Turbopack 設定與自訂配置

大多數情況下 Turbopack 是零配置的，但如果你需要自訂，可以在 next.config.js 裡設定：

// next.config.js
/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    turbo: {
      // 自訂模組解析規則
      resolveAlias: {
        // 替換特定模組（類似 Webpack 的 resolve.alias）
        'old-library': 'new-library',
      },
      // 自訂檔案載入器
      rules: {
        '*.svg': {
          loaders: ['@svgr/webpack'],
          as: '*.js',
        },
        '*.graphql': {
          loaders: ['graphql-tag/loader'],
          as: '*.js',
        },
      },
    },
  },
};

module.exports = nextConfig;

注意 rules 的寫法跟 Webpack 的 loader 設定有點像，但語法更簡潔。Turbopack 刻意保持了部分 Webpack loader 的相容性，所以很多現有的 loader 可以直接沿用。

從 Webpack 遷移的注意事項

遷移過程中我踩了不少坑，這裡分享幾個重點：

1. 不支援的 Webpack 外掛

Turbopack 目前不支援所有 Webpack 外掛。像是 webpack.DefinePlugin 已經內建支援，但一些比較冷門的外掛可能需要找替代方案。建議先用 --turbopack 跑看看，有不支援的它會明確告訴你。

2. CSS Modules 的行為差異

Turbopack 處理 CSS Modules 的方式跟 Webpack 稍有不同。如果你有用到 :global 選擇器或是比較複雜的 compose 語法，可能需要微調。

3. 環境變數

NEXT_PUBLIC_ 開頭的環境變數依然正常運作，但如果你之前有透過 Webpack 的 DefinePlugin 注入自訂變數，需要改用 Next.js 原生的環境變數機制。

# .env.local
NEXT_PUBLIC_API_URL=https://api.example.com
NEXT_PUBLIC_FEATURE_FLAG=true

效能優化實戰技巧

啟用 Turbopack 之後，還有幾招可以進一步榨出效能：

減少不必要的 barrel exports

這點不管用什麼打包工具都很重要。避免這樣寫：

// ❌ 不好的做法 - barrel export
import { Button } from '@/components';

// ✅ 好的做法 - 直接引入
import { Button } from '@/components/Button';

Barrel exports 會迫使打包工具解析整個目錄下的所有模組，即使你只用了其中一個。直接引入可以讓 Turbopack 的 tree shaking 更有效率。

善用動態載入

搭配 Next.js PPR（Partial Prerendering）和動態載入，可以大幅減少初始 bundle 大小：

import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
  loading: () => <div>載入圖表中...</div>,
  ssr: false,
});

監控 bundle 大小

用 @next/bundle-analyzer 搭配 Turbopack 來找出肥大的依賴：

ANALYZE=true npm run build

常見問題與踩坑經驗

Q：Turbopack 可以用在 production build 嗎？

截至 Next.js 15，Turbopack 在 next dev 階段已經穩定。next build 的 Turbopack 支援正在積極開發中，但目前 production build 仍然使用 Webpack。所以你的 CI/CD 流程不需要改動。

Q：跟 Next.js Middleware 相容嗎？

完全相容。Middleware 運行在 Edge Runtime，跟打包工具是獨立的層級，不會有衝突。

Q：我的 Tailwind CSS 能正常運作嗎？

可以。Turbopack 原生支援 PostCSS，所以 Tailwind CSS 不需要任何額外設定就能正常運作。

Q：monorepo 支援如何？

Turbopack 支援 monorepo 結構，但如果你用的是 Turborepo（同樣是 Vercel 的產品），兩者的整合會特別順暢。注意 Turbopack（打包工具）和 Turborepo（monorepo 管理工具）是不同的東西，別搞混了。

結語

Turbopack 不是那種「聽起來很厲害但實際用起來一堆問題」的工具。它真的就是快，而且遷移成本極低——加一個 flag 就好了。如果你每天都在跑 next dev，那省下來的等待時間累積起來是很可觀的。

我的建議是：先在開發環境試試看，感受一下速度差異，再決定要不要全面導入。反正 production build 目前還是走 Webpack，所以完全沒有風險。給自己一個機會體驗一下毫秒級 HMR 的快感吧。