ReactCompiler1.0之后还要手写useMemo和useCallback吗？

核心结论非常明确：在已开启 React Compiler 1.0 的项目中，日常业务开发中绝大多数情况下都不再需要手写 useMemo 和 useCallback。React Compiler（早前代号 React Forget）在代码构建阶段通过静态数据流分析，自动为组件和自定义 Hook 注入细粒度的响应式作用域（Reactive Scopes）和记忆化槽位。只有在代码违背 React 规则被编译器安全跳过、开发需要向下兼容老版本的公开通用组件库，或者与非 React 外部系统交互等极少数边界场景下，手动缓存或明确的引用控制才具有存在价值。

一、日常开发习惯的根本转变：从“预防性手动优化”到“默认自然书写”

在 React Compiler 诞生前，前端团队往往需要建立沉重的心智模型：为了避免子组件无关重渲染，开发者不得不给大部分对象、数组包裹 useMemo，给传递给子组件的事件处理函数包裹 useCallback，并在组件外层包上一层 React.memo。这种开发模式带来了几个顽疾：

• 依赖数组（deps array）维护成本高：人工梳理依赖极其容易产生疏漏，漏填依赖会导致“闭包陷阱（Stale Closure）”，多填或传入新建对象又会导致缓存频繁失效。
• 代码噪点与可读性急剧下降：简单的数学转换、过滤逻辑或函数声明被数层样板代码嵌套，新接手代码的同事很难一眼看清业务逻辑核心。
• 优化粒度依然过粗：手动 useMemo 往往只能针对整块计算进行保活，无法做到局部 JSX 节点或组件内部表达式级别的精准复用。

React Compiler 1.0 的引入彻底扭转了这一规则。现在在业务组件中，开发者应当遵循“声明式原生写法”，直接写普通的计算表达式与普通内联函数。编译器会在编译期自动识别依赖拓扑，按需生成极其细致的缓存，既消除了漏写依赖的隐患，又解放了开发者的心智负担。

二、React Compiler 是如何代替手动记忆化的

理解为什么不用手写，关键在于了解编译器在底层做了什么。React Compiler 并不是在运行时加了一层厚重的代理，而是在构建阶段（Babel / 编译插件）对 JavaScript AST 执行静态分析，将原本单一执行的函数组件拆解为微型的“响应式作用域（Reactive Scopes）”。

例如，下面是一段无需手动编写任何 useMemo 或 useCallback 的标准业务代码：

// 开发者源码：直接书写清晰的纯逻辑
function ProductList({ items, filterText, onSelect }) {
  const filteredItems = items.filter(item => 
    item.name.toLowerCase().includes(filterText.toLowerCase())
  );

  const handleClick = (id) => {
    console.log("Selected product id:", id);
    onSelect(id);
  };

  return (
    <div className="product-list">
      <SearchHeader count={filteredItems.length} />
      <ListBody items={filteredItems} onItemClick={handleClick} />
    </div>
  );
}

当经过 React Compiler 转换后，生成的编译产物大致对应如下形式（概念化伪代码）：

// 编译器生成的产物：自动分配细粒度缓存槽位（Reactive Scopes）
function ProductList({ items, filterText, onSelect }) {
  const $ = useMemoCache(8); // 分配 8 个独立槽位

  let filteredItems;
  if ($[0] !== items || $[1] !== filterText) {
    filteredItems = items.filter(item => 
      item.name.toLowerCase().includes(filterText.toLowerCase())
    );
    $[0] = items;
    $[1] = filterText;
    $[2] = filteredItems;
  } else {
    filteredItems = $[2];
  }

  let handleClick;
  if ($[3] !== onSelect) {
    handleClick = (id) => {
      console.log("Selected product id:", id);
      onSelect(id);
    };
    $[3] = onSelect;
    $[4] = handleClick;
  } else {
    handleClick = $[4];
  }

  let jsxResult;
  if ($[5] !== filteredItems || $[6] !== handleClick) {
    jsxResult = (
      <div className="product-list">
        <SearchHeader count={filteredItems.length} />
        <ListBody items={filteredItems} onItemClick={handleClick} />
      </div>
    );
    $[5] = filteredItems;
    $[6] = handleClick;
    $[7] = jsxResult;
  } else {
    jsxResult = $[7];
  }

  return jsxResult;
}

如上所示，编译器不仅自动完成了 filteredItems（原 useMemo）和 handleClick（原 useCallback）的记忆化，甚至连 JSX 生成树（原 React.memo 才能实现的阻止子树渲染）都自动加入了比对缓存。这种细粒度是人工编写难以企及且极易出错的。

三、操作指南：如何在项目中配置并验证 React Compiler

要让项目真正享受无需手写 useMemo 的红利，需要正确完成工具链配置。整个接入验证过程分为四个标准化步骤：

步骤 1：安装并配置 ESLint 规则检查

React Compiler 能够正常工作的前提是代码必须遵守 React 核心规范（Rules of React）。官方提供了专用的 ESLint 插件，用于在编码阶段定位可能导致编译失败的代码模式。

npm install -D eslint-plugin-react-compiler

在 ESLint 配置文件（如 eslint.config.js）中启用：

import reactCompiler from 'eslint-plugin-react-compiler';

export default [
  {
    plugins: {
      'react-compiler': reactCompiler,
    },
    rules: {
      'react-compiler/react-compiler': 'error',
    },
  },
];

步骤 2：安装编译器核心依赖

编译器通过 Babel 插件实现语法转换。推荐在 React 19 项目中使用，若项目仍在使用 React 17 或 18，还需要额外引入运行时支持包 react-compiler-runtime。

npm install -D babel-plugin-react-compiler

步骤 3：在打包工具中激活插件

以现代前端常见的 Vite 项目为例，在 vite.config.ts 的 React 插件中加入编译器选项：

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: [
          ['babel-plugin-react-compiler', { target: '19' }]
        ],
      },
    }),
  ],
});

步骤 4：在 React DevTools 中验证生效状态

完成配置并启动本地开发服务器后，打开浏览器的 React 开发者工具（React DevTools）：

• 在 Components 选项卡中，检查各个组件节点的右侧；
• 成功被编译器优化的组件，其名称后方会显示一个 "Memo ✨" 徽章；
• 看到该徽章即表明该组件的计算属性、回调函数与渲染树已被编译器全面接管，无需任何手动缓存。

四、哪些情况下仍然需要手动处理或保留 Hook？

尽管日常业务场景已全面告别手写 Hook，但 React Compiler 并非万能魔术。在以下特定边界场景下，开发者依然需要保留或手动编写记忆化逻辑：

1. 违背 React 规范导致编译器跳过（Bailout）

React Compiler 坚持“正确性高于性能”的设计哲学。一旦检测到组件存在无法确定的副作用或突变操作（例如在渲染函数内部直接修改已存在的 props 属性、直接修改全局数组、在渲染过程中读取并写入 mutable ref），编译器会立刻触发 Bailout，安全回退到未经优化的原生状态。

2. 开发面向公众的开源通用组件库

如果你正在维护一个发布到 npm 供第三方调用的通用 UI 库或 Hook 库，你的使用者可能仍然在旧版 Webpack、Next.js 14 或未开启 React Compiler 的环境中运行。此时如果在组件内部完全不写 useCallback，会导致使用者在将其作为依赖传递时频繁触发额外重渲。因此，开源组件库的发布产物中，为了实现向下兼容，仍然需要适度保留 useMemo 和 useCallback。

3. 与非 React 外部系统交互（第三方实例、原生事件监听器）

在与某些对“函数句柄内存地址严格单例”有强要求的底层库（如特定音频工作流 AudioNode、Canvas/WebGL 驱动引擎、原生 DOM 订阅）集成时，如果回调函数的地址每次稍有变动就会触发整个外部引擎的重新销毁与实例化，使用带有明确空依赖 useCallback(fn, []) 或 useRef 显式固定句柄会更加确定可控。

五、存量老项目迁移策略与综合决策总结

许多团队面临的实际问题是：项目中有成千上万处已经写好的 useMemo 和 useCallback，升级后需要专门花时间去删掉它们吗？

答案是：完全没有必要主动批量删除。React Compiler 在设计之初就考虑到了渐进式采纳。编译器能够完全理解现有的 useMemo 和 useCallback，不仅不会与其冲突，还能将其作为输入信号进行协同优化。因此推荐的团队工程实践为：

• 新代码新规范：所有新开发的功能和页面，禁止主动编写防御性的 useMemo / useCallback，让代码保持极简；
• 老代码顺其自然：存量代码中的旧 Hook 保持原样，只在日常业务需求迭代或代码重构修改到对应模块时，顺带将其剔除；
• 监控与规范优先：将精力从“怎么写依赖数组”转移到“遵循 ESLint 规范，编写纯粹函数组件”上。

总结而言，React Compiler 1.0 的到来标志着 React 性能优化正式迈入“工具链自动化时代”。对于绝大多数日常业务开发，手写 useMemo 和 useCallback 已经成为过去式。把缓存与重渲染优化的繁杂琐事交由编译器完成，开发者只需专注于业务逻辑本身，回归简洁、声明式且纯粹的 React 编码体验。