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 個路由)上的實測結果:
| 指標 | Webpack | Turbopack | 提升幅度 |
|---|---|---|---|
| Dev Server 冷啟動 | 8.2 秒 | 1.4 秒 | ~5.8x |
| HMR(修改元件) | 1.2 秒 | 0.05 秒 | ~24x |
| HMR(修改 CSS) | 0.8 秒 | 0.02 秒 | ~40x |
| 記憶體使用量 | 680 MB | 420 MB | ~38% 減少 |
最讓我驚豔的是 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 的快感吧。
繼續閱讀
Next.js 16 View Transitions API 實戰:用原生轉場動畫打造絲滑頁面切換體驗
相關文章
你可能也喜歡
探索其他領域的精選好文