React Compiler：先量再开

Next.js 16 把 reactCompiler 收成稳定开关之后，团队群里常见一句话：开一下试试。真要上生产，我更关心的是它会替你 memo 什么、不会碰什么，以及构建时间这张账单谁来付。

官方文档写得很直白：安装 babel-plugin-react-compiler，在 next.config 里设 reactCompiler: true。它不是 SWC 的替代品，而是在 JSX / Hooks 相关文件上再跑一层编译期优化，目标是少写 useMemo / useCallback，减少无意义重渲染。

它实际在做什么

React Compiler 在构建期分析数据流，自动给组件和 hooks 做记忆化。你以前为了稳住子树，到处撒 memo、useCallback 包一层 props；编译器能证明依赖干净时，会替你做类似的事。

它不是魔法：

有副作用、读写外部可变状态、或者写法让编译器推不干净依赖时，它会直接跳过，组件照旧按 React 规则跑。
SWC 仍负责转译与打包相关的那一截；Compiler 管的是 React 语义上的重渲染成本。
构建会变慢一点。文档也承认依赖 Babel 路径，开发与 CI 都会感受到；Next 还没默认全开，就是在攒更多真实仓库的构建数据。

社区讨论里有人总结得很准：大应用里你已经手写一堆 memo，开 Compiler 换用户侧流畅往往划算；小页面、主要瓶颈在网络和数据，体感可能接近零。

怎么开，以及怎么渐进

最小配置：

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  reactCompiler: true,
};

export default nextConfig;

先装插件：

bash

pnpm add -D babel-plugin-react-compiler

建议同步装 React Compiler 相关 ESLint 规则。很多团队先开 lint，摸清仓库里有多少“编译器不喜欢”的写法，再全量开编译。增量模式（annotation / "use memo"）适合大 monorepo：先给热路径组件打标，观察 Lighthouse、React Profiler 和 CI 时长，再扩大范围。

个别函数或文件需要退出优化时，用 "use no memo" 指令即可，不必整仓回滚。

上线前我都会查这几项

1. 热路径有没有真的变快
Dashboard、无限列表、带复杂 filter 的表格，用 Profiler 看 commit 次数和耗时。若主要卡在服务端拉数或 RSC 外壳，Compiler 帮不上忙，别指望一个开关拯救架构。

2. 手写 memo 要不要清理
Compiler 稳定后，重复的 useCallback 墙可以逐步拆。别第一天就全局删；先对新代码约定“默认交给编译器”，旧代码在改到时再收。

3. CI 预算
在 PR 流水线里单独记一笔 next build 时长。若从 3 分钟变成 5 分钟，要和产品侧的交互收益放同一张表里看，而不是只听“自动优化”四个字。

4. 与 RSC / 客户端边界
Compiler 优化的是客户端 React 树的渲染路径。服务端组件、流式外壳、缓存策略仍是另一套题。别把 RSC 堵死外壳的问题误记到“没开 Compiler”头上。

图：明亮办公桌上的双屏开发环境，左侧浏览器组件树，右侧终端构建日志

和 2026 前端现状怎么叠

LogRocket 等总结里，meta-framework（Next / Nuxt）仍是多数产品团队的默认入口；React Compiler 被 Vite、Expo、Next 等工具链陆续接进来，正在从“实验开关”变成新项目检查清单上的一项。与此同时，AI 生成 UI 变多了，生成代码往往欠一堆手写 memo。Compiler 在这种仓库里反而更有用：机器写的组件树更杂，自动记忆化能兜一部分重复渲染。

反过来也成立：生成代码若充斥不纯渲染、随机数、直接碰 DOM，编译器会安静地跳过。工具救不了语义烂掉的组件。