Next.js 16.3 里的 Turbopack：更稳的开发内存、更快的构建缓存

Next.js 16.3 继续把 Turbopack 往“日常可依赖”的方向推进。这次变化不只是更快：开发模式加入内存驱逐，构建引入持久化文件缓存，还出现了实验性的 Rust React Compiler，以及对 import.meta.glob 的支持。对大型 Next.js 项目来说，这些点分别对应四个真实痛点：内存占用、冷构建、React 编译链路，以及批量导入文件的 ergonomics。

开发模式：内存驱逐让长时间运行更可控

开发服务器最怕的不是启动慢，而是跑了一下午之后越来越重。Next.js 16.3 中 Turbopack 增加 development memory eviction，重点就是让开发模式下的缓存和中间状态可以被更主动地回收。

这类能力对以下项目尤其有价值：

• 页面、组件、MDX 或内容文件数量很多的应用
• 本地开发经常开多个 Next.js 实例的 monorepo
• CI preview、远程开发容器、低内存笔记本环境
• 长时间运行 next dev，频繁切分支或改动大量文件的团队

需要注意，内存驱逐不是“让所有东西都无限快”的魔法。它更像是给开发服务器加了一个更健康的代谢系统：在内存压力变大时，部分可重建状态可以被丢弃，换取更稳定的长期运行。

构建模式：持久化文件缓存改变冷启动体验

另一个更偏工程效率的变化是 build persistent file cache。过去很多构建优化停留在进程内缓存，一旦进程结束，下一次构建仍然要重新计算大量内容。持久化文件缓存的意义在于：构建产物或中间结果可以跨构建复用。

这对本地和 CI 都有直接影响：

• 本地重复执行 next build 时，后续构建有机会减少重复工作
• CI 如果缓存目录配置得当，可以减少每次从零开始的成本
• 大型应用的增量构建体验会更接近“只为变化付费”

可以这样实践：先在一个分支上固定 Node.js、包管理器版本和 Next.js 版本，再观察启用 Turbopack 构建前后的时间、缓存大小和稳定性。

# 以 pnpm 项目为例；请按你的项目实际包管理器替换
pnpm install

# 开发模式，观察长时间运行时内存是否更稳定
pnpm next dev --turbo

# 构建模式，连续执行两次，比较第二次是否复用更多缓存
pnpm next build --turbo
pnpm next build --turbo

如果你在 CI 中缓存 Next.js 相关目录，可以从保守配置开始。下面是一个可改造的 GitHub Actions 示例，假设项目使用 pnpm：

name: next-build

on:
  pull_request:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 9

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm

      - name: Restore Next.js cache
        uses: actions/cache@v4
        with:
          path: |
            .next/cache
          key: next-cache-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}-${{ github.sha }}
          restore-keys: |
            next-cache-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}-
            next-cache-${{ runner.os }}-

      - run: pnpm install --frozen-lockfile
      - run: pnpm next build --turbo

这里的关键不是盲目缓存所有目录，而是先缓存 .next/cache，并用 lockfile 作为缓存键的一部分，避免依赖变更后复用不合适的缓存。

Rust React Compiler：实验性意味着要小步试点

Next.js 16.3 还带来了 experimental Rust React Compiler。这个方向很有意思：React 编译相关工作如果能进入更底层、更高性能的实现，理论上可以减少 JavaScript 编译链路中的部分成本。

但“experimental”这个词要认真对待。它适合：

• 在非核心页面或内部应用中试点
• 用真实业务组件验证兼容性
• 对比构建时间、运行行为和产物差异
• 保留快速回滚方案

不建议一上来就在关键生产应用里全量打开。更稳的方式是为一个应用、一个包或一个分支启用实验配置，再让测试、类型检查和端到端用例一起兜底。

可以这样做一个试点分支：

git checkout -b try-next-16-3-turbopack
pnpm add next@latest react@latest react-dom@latest
pnpm test
pnpm next build --turbo

具体实验开关请以当前 Next.js 版本文档和项目配置为准；实验能力的名称、默认值和限制都可能继续变化。

import.meta.glob：批量导入内容文件更顺手

import.meta.glob 支持是一个很实用的开发体验改进。它常见于内容站、文档站、组件示例库：你想从一个目录批量收集模块，而不是手写一串 import。

假设有这样的目录：

app/
  blog/
    page.tsx
content/
  posts/
    hello.mdx
    turbopack.mdx

可以这样实践，批量读取文章模块。下面示例是假设项目已配置好 MDX 支持：

// app/blog/page.tsx
const postModules = import.meta.glob('../../content/posts/*.mdx');

export default async function BlogPage() {
  const posts = await Promise.all(
    Object.entries(postModules).map(async ([path, load]) => {
      const mod = await load();
      return {
        path,
        metadata: (mod as { metadata?: { title?: string } }).metadata,
      };
    })
  );

  return (
    <main>
      <h1>Blog</h1>
      <ul>
        {posts.map((post) => (
          <li key={post.path}>{post.metadata?.title ?? post.path}</li>
        ))}
      </ul>
    </main>
  );
}

要改的地方很明确：把 ../../content/posts/*.mdx 换成你的内容目录；如果你的 MDX frontmatter 字段不是 metadata.title，同步调整读取逻辑。

升级建议：把 Turbopack 当成工程系统来验证

这次更新的几个点都指向同一个方向：Turbopack 不再只是“开发服务器更快”的卖点，而是在构建缓存、内存管理、编译器集成和模块导入语法上补齐工程能力。

落地时建议按这个清单推进：

• 先在分支上升级 Next.js 16.3，并固定 Node.js 与包管理器版本
• 对比 next dev --turbo 的长时间内存曲线，而不是只看启动时间
• 连续跑两次 next build --turbo，记录冷构建和热构建差异
• 在 CI 中谨慎缓存 .next/cache，避免缓存键过宽
• 对 experimental Rust React Compiler 保持小范围试点
• 如果项目有内容目录或示例目录，优先尝试 import.meta.glob

最好的升级策略不是“一键打开所有开关”，而是把每个新能力映射到项目里的具体痛点：内存不稳、构建太慢、内容导入繁琐，哪个最痛，就先验证哪个。