Next.js 16.3 已经稳定一阵了。官博里写得最醒目的是 Instant Navigations，团队群里聊得最多的，其实是另一件事：dev server 内存终于不那么离谱了。
我这边一个中型 monorepo，以前 next dev 开半天，任务管理器里 Node 轻松顶到十几 GB。有人在 discussion 里报过从约 20GB 掉到 5GB；Vercel 自己的 dashboard 示例更夸张，编译五十来个路由后，从 21.5GB 收到 2GB 左右。数字会随项目浮动，方向是清楚的：冷编译状态不再死死占着内存。
以前卡在哪
App Router 项目一开，Turbopack 要把大量路由的编译图、模块图、转换缓存挂在进程里。路由越多、共享包越深，常驻集合越大。你不是一直在编译那五十个页面，但它们的中间态还在。
长会话尤其难受。上午开着 dev，下午切两个 feature branch，内存只上不下。重启成了习惯，HMR 状态、登录 cookie、本地 mock 一起清掉，节奏被打断。
这不是“机器不够好”那么简单。很多人本机 32GB，IDE、浏览器、Docker 再各占一截，留给 Node 的余量本来就紧。dev server 再吃十几 GB，整机开始换页，编辑器也跟着卡。
图：长会话里，冷路由的编译状态更适合待在磁盘，而不是堆里
16.3 默认做了什么
核心变化可以概括成两块，而且默认打开：
- 磁盘缓存（dev）：编译产物和可复用状态落盘，下次启动、冷路由不必从零重算。
- 内存回收（memory eviction）：一段时间不用的编译状态从 RAM 挪到文件系统缓存，而不是一直钉在堆里。
官方在 Turbopack 相关说明里把两者绑在一起讲。你升级到 16.3 之后，通常不用改 next.config 就能感觉到长会话更稳。构建侧还有可选的 filesystem cache 开关，那是另一条线；日常开发体感主要来自 dev 默认策略。
可以粗暴理解成：热路径仍在内存，冷路径允许换出。和操作系统对页面缓存的态度类似，只是对象换成了 bundler 的中间表示。
我怎么验收，而不是看宣传图
升级前后我只盯三件事：
- 连续工作 2–4 小时后，Node 进程 RSS 是否还单调爬升
- 冷启动到可交互的时间是否可接受（落盘多了，第一次可能稍慢，第二次应回本）
- 改一个深层 shared 包时，HMR 是否仍可靠，有没有“内存省了、热更新坏了”的副作用
命令很土，够用：
# 记升级前基线：开 dev，点 30+ 路由，挂 2 小时
# Windows 用任务管理器或 Get-Process；macOS/Linux 可用：
ps -o rss=,command= -p $(pgrep -f "next dev")
更省事的做法是：同一仓库、同一 Node 版本，开两个 worktree，一个钉在 16.2，一个升 16.3，并排跑同样的点击脚本。不要只看首页，要进后台、设置页、带动态段的列表。内存尖峰往往出现在“第一次走进冷路由簇”的时候。
如果 RSS 降了但某个路由 HMR 偶发丢样式，先查是不是自定义 webpack/turbopack 插件还在假设“一切常驻内存”。插件若缓存了已被 eviction 的模块引用，就会出现幽灵状态。这类问题比版本本身更常见。
和 Instant Navigations 别混谈
16.3 的另一半叙事是导航体感：partial prefetch、壳先行、路由级缓存。那是用户点链接之后的故事。
dev 内存是你写代码时的故事。两者可以一起升，但排障要分开。线上 LCP 没变、本机风扇不转了，是内存这条线的功劳；本机内存依旧炸、线上点击却更跟手，才是导航套件的问题。
团队里有人一升级就先开 Instant 相关实验旗标，结果回归测全挂在预取和 cookie 边界上，反而觉得 16.3 “不稳”。建议：先吃默认的 Turbopack 内存改动，稳定一周，再单独开导航套件，并准备 instant() 一类回归（官方在 v0 迁移里演示过用测试钉住慢路由）。
什么时候不该急着升
- 你们锁死了自定义 Turbopack/webpack 插件，且依赖未声明的内存常驻行为
- CI 镜像还在旧 Node，本地 16.3、流水线 16.1，讨论问题会对不上
- 主要痛点其实是生产 bundle，而不是 dev RSS——那应该先看打包分析和 RSC 边界，而不是指望 dev eviction
反过来，若你们已经靠“每两小时重启 dev”续命，16.3 值得排进本周的补丁窗口。风险通常低于一次 App Router 大迁移，收益却每天都能摸到。
小结
Next.js 16.3 里，Instant Navigations 适合写进 changelog 标题；Turbopack 默认把冷编译状态换出到磁盘，更适合写进你们的工程备忘录。先量 RSS 和长会话稳定性，再决定要不要碰导航实验项。内存降下来之后，你才会有耐心去调那些真正影响产品的预取策略。
