👁 82 次阅读

Turbopack 开发服务器内存为何暴涨到 8GB？

现象描述

https://github.com/dokugo/next-reown-appkit-memory-usage

• 仅运行 npm run dev 并打开 localhost，就达到约 2000 MB RAM
• 访问 15 个空白路由后，开发服务器进程约 8000 MB（Webpack 下约 2500 MB）
• 每次路由编译新增约 400 MB
• 每次路由编译出现持续数秒的高 CPU 峰值
• 路由编译速度约为 Webpack 的 1/5
• HMR 占用约 5% CPU，而通常为 0.1%
• 硬刷新每次新增约 30 MB，持续增长直至 OOM

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 65144
  Available CPU cores: 16
Binaries:
  Node: 22.16.0
  npm: 10.9.2
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.3.4
  eslint-config-next: 15.3.4
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.8.3
Next.js Config:
  output: N/A

背景原因

• Remix（React Router 7）
• Tanstack Start
• CSR React + Vite

排查或量化方法

{
  "experimental": {
    "turbopackFileSystemCacheForDev": false
  }
}

常见错误排查

• 开发服务器卡在 “compiling…” 并持续高 CPU：gabriele-ferri 在 Next 16.1.6 上报告了该现象，并伴随大量 CPU 与 RAM 占用。
• 编译一开始就出现 CPU 与内存峰值：This-is-Prateek 在 Next 16.2.0 上报告了相同表现。
• 只想先绕过问题：wuguoguang 在 Next 16.1.6 上提问是否只能退回 Webpack 才能规避，并要求其它可行 workaround；该条评论下方在给出的摘录中未见明确答复。
• 在同一配置下仍不可用：wof-git 在测试 16.3.0-preview.10 后明确写出，空闲增长机制看似消失，但这是冷缓存测试，并不复现此前失败的条件，因此不应将其当作确认。
• 排查时口径不一致：Kerbz-dev 特别说明使用了隔离 worktree，确保 turbopack.root 下没有既有 .next* 目录，并开启 NEXT_TURBOPACK_TRACING=1；缺少这些前置条件时，对比数值可能不可比。

实践建议

• 升级到 16.3 及以上版本，这是在 issue 中获得维护者认可的处理方向。在 16.3.0-preview.6 上做重测的用户同时使用了 experimental.turbopackMemoryEviction: "auto"，可作为对照实验的一部分。
• 若仍在 16.2.x 上，据 issue 讨论可关注 experimental.turbopackFileSystemCacheForDev，有用户将其列为 RAM 增长的可归因项，并指出默认值为 true。同一用户在 16.3.0-preview.10 中核对该默认值仍未改变（引用位置 next/dist/server/config-shared.js:283），即未显式关闭的用户在新版本上仍默认吃到该配置。
• 若遇到进程数暴涨形态的故障，注意该故障表现为 worker 进程风暴：一旦缓存变大，PostCSS worker 拿不到所需内存即 SIGABRT，随后被逐请求无退避地重建，12 秒内可从 4 个进程涨到 166 个。这类症状在应用侧表现为接口返回 500，容易误判为凭据提供方限流。
• monorepo 场景需要显式关注 turbopack.root 与 transpilePackages 的组合。Kerbz-dev 的报告正是围绕 monorepo 根目录下的 turbopack.root 与三个 transpilePackages 工作区包展开的。
• 做前后对比时，删除活动 .next 目录，并在隔离环境里运行，避免旧缓存画像污染结论。wof-git 也提醒冷缓存测试不等于复现原失败条件。
• 报告者所用的最小复现仓库仍可作为对照样本：https://github.com/dokugo/next-reown-appkit-memory-usage，配合依次访问 route 0 到 route 14 的路径，能较快看出单次编译的内存增量。
• 若升级后仍遇到高内存占用，按维护者要求提交带复现案例的新 issue。

FAQ