Next.js 为什么这么卡？Turbopack + React Compiler + 显式缓存 + Server-fi

Next.js “卡”这件事在社区已经吵了快4年了，从13到16版本都有人天天喊“dev server 巨慢”“hydration 爆炸”“生产也莫名其妙慢”。

但实际情况是：Next.js 本身不一定卡，大部分时候是“使用方式 + 项目规模 + 配置”把它搞卡了。

下面按出现频率从高到低，把2025~2026年最常见的“卡点”+真实占比+解法列出来（基于Reddit、GitHub issues、各种中文社区观察）：

排名	卡点类型	出现频率（2025-2026）	典型表现	根本原因简析	解法优先级 & 效果预期
1	dev server 编译/HMR 巨慢	★★★★★	保存改动等5~30秒，改个className都卡	Webpack冷启动/增量更新差 + 大项目路由多 + barrel文件	Turbopack（Next 16默认）可提速3~10倍
2	Hydration 时间长/白屏/卡顿	★★★★	生产环境TTI 1~5秒+，低端手机更惨	组件树太大 + 过多Client Component + 大bundle	React Compiler + 拆分Client + Suspense
3	生产环境TTFB/整体加载慢	★★★	首屏2~8秒，LCP很差	中间件写db查询/慢API + 没开边缘缓存 + 滥用SSR	边缘中间件 + PPR + 缓存优化
4	构建时间爆炸（CI慢死）	★★★	next build 10~40分钟+	monorepo + 没远程缓存 + Turbopack不稳定	Turbopack + Turborepo远程缓存
5	内存爆炸/OOM	★★~★★★	dev/build 吃10~20GB+内存直接崩	大型项目 + 很多动态import + 没清理node_modules	升级Node 20/22 + Turbopack + 分包
6	路由切换慢（客户端导航）	★★	点击链接等1~3秒才响应	prefetch滥用 + 大量Client组件重渲染	优化prefetch + 用`loading.js` + React Query
7	Next 15/16 升级后反而更卡	★★	升级完发现请求翻倍/构建更慢	缓存策略大改 + 新编译器bug + 兼容性问题	看changelog + 用`--turbo`测试

“我明明写得很规范还是巨慢”型
- 特征：中大型项目（>100页面），还在用 webpack，dev 改动等5~15秒
- 现状：Next.js 16 已默认 Turbopack，绝大多数人只要把 next dev 改成 next dev --turbo（或配置默认）就能立刻体验到质的飞跃（很多项目HMR从8秒→1秒以内）
  → 解法：先升级到最新16.x，开启 Turbopack，99% 能解决 dev 卡的问题
“生产环境才知道它有多卡”型（最致命）
- 典型场景：复杂后台/中台/SaaS，页面组件树深，Client Component 多
- 核心杀手：hydration 阶段主线程阻塞（低端手机1~4秒白屏可交互）
- 现状：React 19 + React Compiler 已经能自动 memo 掉大部分手动 useMemo，但前提是你大量使用 Client Component
  → 解法优先级：
  1. 尽量把数据获取/逻辑留在 Server Component
  2. 开 reactCompiler: true
  3. 用 Suspense + streaming 把大块内容分块
  4. Client 组件能 lazy 就 lazy
“我也不知道为什么，就是慢”型（排查地狱）
- 常见元凶：
  - middleware 里写了数据库查询/第三方慢API
  - 滥用 fetch 没设置 cache/next: { revalidate: xxx }
  - 到处 "use client" + Context 狂传大对象
  - barrel 文件（index.ts 导出所有）+ monorepo 没远程缓存

Next.js 16 + Turbopack + React Compiler + 正确的使用姿势下，其实已经非常快了（很多中大型项目 dev 体验接近甚至超过 Vite）。

它之所以还被很多人骂“卡”，主要是因为：

快速自测清单（照着做，80% 的“卡”都能改善）：