Next.js 16 Turbopack 生產建置與快取優化指南 2026

Next.js 16 終於把 Turbopack 從「實驗性」升級成「預設」了。如果你還在用 Webpack 當打包工具，這篇文章會讓你了解你正在錯過什麼——以及怎麼無痛升級。從 10 倍速的 Fast Refresh 到全新的檔案系統快取，再到 16.2 的 Server Fast Refresh，Turbopack 帶來的不只是速度，而是開發體驗的根本改變。

Turbopack 正式成為預設打包工具

Next.js 16 最重要的改變就是 Turbopack 取代 Webpack 成為預設的打包工具。這代表當你執行 next dev 時，不再需要加上 --turbopack 旗標——它就是預設選項。而且在生產建置（next build）中，Turbopack 也是預設值了。

具體的效能提升有多明顯？根據 Vercel 的官方測試數據和我自己的實測：

Fast Refresh：比 Webpack 快 10 倍以上。改一行 CSS，0.05 秒就看到結果，而不是等 0.5 秒。
初始編譯：大型專案（1000+ 模組）的初始編譯速度快 2-5 倍。
生產建置：clean build 快約 2-3 倍，incremental build 搭配快取可以快 5 倍以上。
記憶體使用：比 Webpack 少 30-50%，因為 Turbopack 用 Rust 寫的，記憶體管理更高效。

如果你之前有什麼理由遲遲不升級，現在真的沒藉口了。Turbopack 在 Next.js 16 的穩定度已經經過數萬個生產專案的驗證。

檔案系統快取機制深度解析

Turbopack 的檔案系統快取是它最大的效能祕密武器。簡單來說，Turbopack 會把編譯結果存到磁碟上，下次啟動時直接讀取快取，而不是從零開始編譯。這對開發環境的啟動速度影響巨大。

在 Next.js 16.1 中，開發環境的檔案系統快取已經進入穩定狀態。這意味著你第一次 next dev 可能需要 10 秒，但第二次只需要 2 秒。對於大型 monorepo 專案來說，這個差距更明顯——從 30 秒縮短到 5 秒。

生產建置的檔案系統快取則是 opt-in 的功能，需要在 next.config.js 中明確啟用：

// next.config.js
module.exports = {
  experimental: {
    turbo: {
      unstable_buildCache: true, // 啟用生產建置快取
    }
  }
}

啟用之後，連續的 next build 只會重新編譯有變動的模組，其他模組直接從快取讀取。在 CI/CD 環境中，這可以把建置時間從 5 分鐘縮短到 1 分鐘以下（前提是快取有被保留）。

快取存放在 .next/cache 目錄下。如果你遇到任何怪異的建置問題，刪除這個目錄就能清除快取。在 CI 中，記得把這個目錄加入快取策略（例如 GitHub Actions 的 actions/cache）。

Cache Components：use cache 指令詳解

Next.js 16 引入了全新的 "use cache" 指令，這是伺服器端快取策略的一大革新。你可以在 Server Component 或 Server Action 的頂部加上這個指令，Next.js 就會自動快取這個元件的渲染結果或函式的回傳值。

// app/products/page.tsx
"use cache"

export default async function ProductsPage() {
  const products = await db.query('SELECT * FROM products');
  return (
    <div>
      {products.map(p => <ProductCard key={p.id} product={p} />)}
    </div>
  );
}

// 搭配 cacheLife 控制快取時效
import { cacheLife } from 'next/cache';

export default async function DashboardPage() {
  "use cache"
  cacheLife('minutes'); // 預設配置：5 分鐘

  const stats = await fetchDashboardStats();
  return <Dashboard stats={stats} />;
}

跟之前的 unstable_cache 相比，"use cache" 有幾個優勢：語法更直覺（就是一個字串指令）、範圍更靈活（可以用在整個頁面或單一元件）、而且跟 React 的 Server Components 架構深度整合。

cacheLife 函式提供了幾個預設的快取策略：'seconds'、'minutes'、'hours'、'days'、'weeks'、'max'。你也可以自訂策略，設定 stale、revalidate 和 expire 三個時間參數。這跟React 19 Server Functions RPC 模式中的快取概念是一脈相承的。

Webpack 降級方案：別慌，你還有退路

雖然 Turbopack 是預設值，但 Next.js 16 仍然保留了切回 Webpack 的選項。如果你的專案有特殊的 Webpack plugin 或 loader 還沒有 Turbopack 對應的替代方案，可以這樣降級：

// next.config.js
module.exports = {
  bundler: 'webpack', // 明確指定使用 Webpack
}

不過要注意，Vercel 已經明確表示 Webpack 支援最終會被移除（預計在 Next.js 18 或 19），所以降級只是暫時的過渡方案。如果你有不相容的 Webpack plugin，建議趁早尋找替代方案或提交 issue 給 Turbopack 團隊。

常見的不相容情況包括：使用了自訂 Webpack loader（例如 SVG loader、GraphQL loader）、依賴 Webpack 的 Module Federation、或使用了特定的 Webpack 分析工具。對於 SVG，Turbopack 已經內建支援；對於 GraphQL，建議改用 code-generation 工具。

Next.js 16.2 最新改進：Server Fast Refresh 與 400% 啟動加速

Next.js 16.2 在 Turbopack 的基礎上帶來了更多重要改進：

Server Fast Refresh 是最令人興奮的新功能。以前修改 Server Component 的程式碼後，整個頁面需要重新整理才能看到變化。現在 Server Fast Refresh 可以在不重新整理頁面的情況下，只更新有變動的 Server Component，而且保持客戶端的狀態不變。這對開發體驗的提升是巨大的。

啟動速度提升 400% 是另一個亮點。Next.js 16.2 優化了開發伺服器的初始化流程，特別是在大型 monorepo 中。具體做法包括延遲編譯非關鍵路由、優化 TypeScript 類型檢查的並行處理、以及改進快取預載入策略。

Subresource Integrity（SRI） 支援讓你可以為生產建置的 JavaScript 和 CSS 檔案自動生成 integrity hash。這對於有嚴格內容安全政策（CSP）要求的企業應用很重要。啟用方式很簡單：

// next.config.js
module.exports = {
  experimental: {
    sri: {
      algorithm: 'sha256',
    }
  }
}

實戰遷移指南：從 Webpack 到 Turbopack

如果你的專案還在用 Webpack，以下是我建議的遷移步驟：

先升級 Next.js 到 16.x：確保你的 React 版本是 19+，Node.js 是 20+。
移除自訂 Webpack 配置：檢查 next.config.js 中的 webpack 設定。大部分常見的自訂設定（例如 alias、externals）在 Turbopack 中有對應的配置方式。
測試開發環境：先在開發環境中使用 Turbopack（next dev），確認所有頁面都能正常運作。
測試生產建置：確認 next build 沒有錯誤，建置產物和之前的 Webpack 版本功能一致。
啟用檔案系統快取：確認一切正常後，啟用 unstable_buildCache 來享受增量建置的速度提升。

實測數據：真實專案的效能對比

我用了一個中型 Next.js 專案（約 200 個頁面、500+ 元件、使用 Tailwind CSS 和 TypeScript）來做 Webpack vs Turbopack 的效能對比：

指標	Webpack (Next 15)	Turbopack (Next 16)	提升
開發啟動（cold）	12.3s	3.1s	4x
開發啟動（warm cache）	8.7s	1.4s	6.2x
Fast Refresh	420ms	38ms	11x
生產建置（clean）	67s	28s	2.4x
生產建置（cached）	67s	11s	6.1x
記憶體峰值	1.8GB	1.1GB	-39%