跳到主要内容

Turbopack

Turbopack 需要放在 Next.js 生态里理解。它不是一把独立流行起来的通用构建工具，而是 Next 路线里最重要的下一代 bundler。

它在解决什么​

核心还是老问题：

  • 大型项目 dev 反馈越来越慢
  • HMR 变钝
  • 构建链路复杂
  • Next 项目需要一套更强的增量打包能力

为什么它重要​

Next 16 已经把 Turbopack 设为默认 bundler。这意味着它不再只是“实验功能”，而是 Next 主线工程体验的一部分。

在项目里怎么用​

最常见的接入方式，不是单独安装一整套 Turbopack 项目，而是直接在 Next.js 里使用。

next dev --turbopack

一个更进阶的 Next 配置参考​

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  experimental: {
    optimizePackageImports: ['lodash-es', 'date-fns'],
  },
  turbopack: {
    resolveAlias: {
      '@': './src',
    },
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
}

export default nextConfig

这里更该留意的，不是配置项名字，而是：Next 项目里原本靠 Webpack 做的事情，迁到 Turbopack 之后边界还在不在。

前端团队更该关心什么​

1. 和 Webpack 的差别​

Next 老项目里，很多构建习惯和兼容假设都来自 Webpack。迁移到 Turbopack 时，最值得看的不是“命令换了没有”，而是：

  • 自定义构建行为是否还能平移
  • 某些插件链是否需要重新评估
  • 开发态和生产态能力成熟度是否一致

2. 开发体验​

Turbopack 的第一价值，通常体现在开发态：

  • 启动更快
  • 增量更新更轻
  • 大项目里反馈更及时

3. 与 Next 配置的边界​

项目里更常见的不是“单独配 Turbopack”，而是确认这些能力和它如何相处：

  • next.config.ts
  • 路由分包
  • 图片和字体处理
  • Server Components
  • App Router 构建链

一个更实际的判断​

Turbopack 本身不是孤立的一层。它会和这些内容一起出现：

  • App Router
  • Server Components
  • 路由分包
  • Next 构建产物
  • 自定义配置边界

所以这篇更适合和 Next.js 专题 互相参照着看。