8 月 3 日，Vercel 发布了 Next.js 16.3 稳定版，这是去年 16.0 以来最大的一次次版本更新。知乎前端圈里传得最凶的一个数字是：Turbopack 开发服务器内存占用最多减少 90%，官方演示里 vercel.com 的 dashboard 项目从 21.5GB 直接压到 2GB。Next.js 官方博客
但没几天，就有国内开发者拿自己的项目实测泼了冷水。他用 MkSaaS 模板测了一轮，结论是开发模式下内存只下降约 20%，首页冷编译明显加快——自测没有官方说得那么夸张，但效果还是有的。小红书
两个数字都是真的。而它们之间的差距，恰恰决定了这次更新对你值不值。
这 90% 是怎么省出来的，为什么你实测只有 20%
先说清楚 90% 是怎么省出来的，不然这个数字就是玄学。
Turbopack 的核心设计是增量编译：编译成本和你这次的改动量成正比，而不是和整个路由树成正比。为了做到这一点，官方早期做了一个刻意的取舍——把更多编译结果缓存在内存里，换更低的 CPU 占用。代价就是内存一路涨：你摸过的每个路由、每次编译的中间产物，都堆在内存缓存里，dev 会话开得越久越夸张。知乎
16.3 就是对这个取舍的回调。做法分两层：
一是大量的小优化，压缩数据结构、缩短缓存里数据的保留时间；二是大头——memory eviction（内存驱逐）。借助 16.1 引入的开发文件系统缓存，Turbopack 现在可以把内存里的缓存结果落到磁盘、然后从内存里清掉。内存缓存不再死守每一个访问过的路由，长时间 dev 会话的内存就不会无限膨胀了。
这两个能力（开发磁盘缓存 + 内存驱逐）在 16.3 里默认开启，不用改任何代码。如果排查缓存相关问题，可以用 `experimental.turbopackMemoryEviction: false` 关掉，默认值是 `auto`。Next.js 官方博客
看官方那组跑分的条件：编译 50 个路由之后测内存。vercel.com dashboard 是巨型路由图，21.5GB 降到 2GB，降幅约 90%；nextjs.org 本身是 4600MB 降到 840MB，约 82%。
注意这两个前提：一是路由图足够大，二是开发会话足够长、摸过的路由足够多。官方自己也明说了——不存在一个适用于所有项目的降幅百分比，实际结果取决于三个变量：路由图的规模、一次开发会话里你摸过多少路由、会话跑了多久。知乎所以那位实测 20% 的朋友并不是翻车：模板级项目的路由图本来就小，内存基数低，驱逐机制能腾出来的空间自然有限。但他的另一半结论同样重要——冷编译明显加快，这个收益是实打实的。
一句话总结：项目越大、dev 开得越久，90% 这个数字越接近你；项目越小，你拿到的更多是编译速度和稳定性收益，而不是内存数字。
升级之前，四个场景自查
这次 16.3 的 Turbopack 相关改进不止内存，升级前建议按自己的场景对一遍：
场景一：大项目 + 长时间 dev + 内存经常顶满。 这是本次更新的第一受益人。现在跑 dev 的不只是你一个人——编码 Agent、IDE、类型检查器、linter 全都在开发时同时吃内存，会话一长，内存压力比前几年更尖锐。Next.js 官方博客官方说的 90% 就是冲你们来的，直接升，升完观察一个下午的常驻内存再说。
场景二：在意 CI 构建时间。 16.1 就有的开发磁盘缓存，这次正式用到了 `next build` 上，而且默认开启。官方在 Vercel 自己项目上 dogfooding 了几个月的数据：nextjs.org 冷构建 21 秒、命中缓存后 9.2 秒，约 2.3 倍；vercel.com/geist 从 30 秒降到 5.5 秒，约 5.5 倍；最保守的 vercel.com/home 也有 1.4 倍。但有个关键前提：缓存在 `.next/cache` 目录，CI 上只有把这个目录在多次 job 之间持久化、恢复回来，构建才会变快。CI 配置里没做缓存恢复的，这个收益等于零——这是最容易白高兴一场的坑。知乎
场景三：小项目。 内存降幅可能感知不强，但其他几项是白捡的：App Router 渲染层换成了原生 Node.js streams，官方基准里负载下最多多处理 22% 的请求；HMR 订阅做了精简，复杂应用的 dev 冷启动快了 15% 以上；运行时产物也更小了，WASM、worker、顶层 await 这些运行时代码改成按需下发。这些都不需要改代码。Next.js 官方博客
场景四：还在用 `–webpack` 的。 16.3 新增的 `import.meta.glob`（Vite 兼容的批量导入 API，支持 eager 模式、负向模式、TypeScript 类型生成）是 Turbopack 独占能力，`–webpack` 构建用不了。这也算官方在提醒你：Turbopack 从 16.0 起就是 dev 和 build 的默认打包器，webpack 选项正在变成孤岛。
另外两个实验性开关值得知道：Rust 版 React Compiler（`reactCompiler: true` 加 `experimental.turbopackRustReactCompiler: true`），官方在 v0 这种大型应用上测出 next dev 冷启动快 34%、热启动快 46%，前提是完全脱离 Babel；TypeScript 7 类型检查（装 `typescript@^7` 即可在 next build 里用），官方口径是 10 倍于旧版的速度。这两个都还带实验性质，不建议盲目上生产。
社区报上来的坑，和一套能照做的验证方法
吹完收益说风险。16.3 上线这三周，GitHub 上的新 issue 值得升级前扫一眼：
有用户报告 16.3.1 上 Turbopack 首次 GET / 耗时 23.3 秒（8 月 20 日提交，还在处理中）；
一个更隐蔽的 bug：`generateComponentChunks` 可能让页面永久停在未水合状态且不报错，运行时需要的那个 chunk 一直没被注入（8 月 20 日）；
还有人在 16.2.6 和 16.3.1 上观察到：每次页面渲染，dev 服务器会多留约 3.9MB 和一个 V8 原生上下文不释放——注意，这是内存驱逐之外的另一路泄漏，说明"内存焦虑"还没到彻底解决的时候；
其余还有模块解析顺序、pnpm workspace 嵌套依赖触发 ELOOP、动态 import 占位符解析等零散问题。
再往前追溯，7 月份有国内开发者实测 16.3.0-preview.5，在 Windows 上遇到了包括 os error 5 在内的回归，当时他的结论是把项目留在稳定版、只把 preview 当观察分支。正式版合入了 16.2 补丁线的全部修复，也修了 Windows 上 `import.meta.url` 的文件 URL 问题，但如果你用 Windows 开发，升级后先跑一轮完整业务路径再合并依赖变更，依然是更稳的姿势。知乎
升级之后如果内存或构建数据不符合预期，给一套可以直接照做的动作：
升级前，在现在版本上正常跑一个完整开发会话（把常用路由都点一遍），记录 next dev 进程的常驻内存；
升级到 16.3（`npm install next@latest`），同样的路径再跑一遍，对比内存和首次编译耗时；
如果内存数据不符合预期，先确认开发文件系统缓存确实开着（它是内存驱逐的前提），再看自己的路由图和会话时长是不是真的够"大"；
CI 场景：确认 `.next/cache` 被缓存恢复，对比升级前后的构建耗时，别只看本地体感；
遇到疑似缓存引起的怪问题，先用 `turbopackMemoryEviction: false` 关掉驱逐做对照，能快速定位是不是新机制引入的。
接下来值得盯的信号
短期看 16.3.x 补丁线。上面提到的几个 issue 如果在你项目里命中，等补丁比硬扛划算。
中期看 Rust React Compiler 什么时候转正。它和 Turbopack 的结合方式（直接在打包器内部跑原生编译器，省掉 Babel 的解析和生成开销）是这次更新里最有想象空间的部分，v0 上 20%–50% 的编译提速已经验证了方向。
长期看 Turbopack 的生态外溢。蚂蚁的新一代 Rust 构建工具 utoo/pack（Mako 的继任者）直接依赖 Turbopack 的核心 Rust crate——Turbopack 的底子是 turbo-tasks 增量计算引擎，它把构建的每一步缓存成"value cell"、追踪彼此依赖、变化时只重算受影响的部分，这正是 utoo/pack 复用的核心能力。知乎目前 umi、father、dumi 和 Ant Design Pro v6 都已接入，npm 周下载量约 9 万；另一边，今年 2 月 Cloudflare 用 AI 一周重写 Next.js 的 vinext 项目选了 Vite 而不是 Turbopack，也提醒着这条路线并非没有竞争。Turbopack 正在从"Next.js 的打包器"变成一套更通用的增量编译基础设施，这个趋势本身比任何单次跑分都值得关注。
结论一句话： 16.3 对大项目长会话开发是今年最值得升的一次更新，CI 记得恢复 `.next/cache`，小项目白拿速度和稳定性收益，Windows 用户升完多跑一遍业务，实验性开关先别上生产。至于 90% 还是 20%，拿你自己的项目测一次，比争论官方跑分有意义得多。
