别再写useMemo了——2026年这5个React性能优化已经是反模式

打开任何一个AI辅助开发的React项目，你大概率会看到同样的画面：useMemo、useCallback、React.memo铺天盖地，仿佛不写就会崩。

但2026年了，React Compiler已经正式落地。你手动写的那些"优化"，很多不但没用，还在拖慢你的代码。

先说结论：为什么要改

React Compiler（随React 19正式推出）做了一件事：在编译阶段自动分析组件，在表达式级别做细粒度memoization。

这意味着：你手写的useMemo、useCallback、React.memo------编译器都能自动做，而且做得更细、更准确。

手动写的问题在于：

维度	手动优化	React Compiler
粒度	组件/Hook级别	表达式级别（更细）
准确性	依赖数组经常写错	编译器分析，不会遗漏
代码量	多30-50%包装代码	零额外代码
维护成本	依赖变了要手动更新	自动追踪
出错概率	依赖数组写错=缓存永远不更新	不存在这个问题

ESLint React v5.3已经加了 no-unnecessary-use-memo 和 no-unnecessary-use-callback 规则------官方工具链都在告诉你别写了。

下面逐个看5个已经变成反模式的"优化"。

反模式1：useMemo包裹所有计算

最常见的AI生成代码模式：

jsx 复制代码

function UserList({ users, filter }) {
  const filteredUsers = useMemo(() => {
    return users.filter(u => u.name.includes(filter));
  }, [users, filter]);

  const sortedUsers = useMemo(() => {
    return [...filteredUsers].sort((a, b) => a.name.localeCompare(b.name));
  }, [filteredUsers]);

  const stats = useMemo(() => ({
    total: sortedUsers.length,
    active: sortedUsers.filter(u => u.active).length,
  }), [sortedUsers]);

  return <div>{/* ... */}</div>;
}

三个useMemo做了一件事：过滤+排序+统计。

React Compiler会自动分析这段代码的依赖关系，在users或filter没变的时候跳过所有计算。你手写三个useMemo，其实在做编译器已经做了的事，同时还增加了：

三个依赖数组的维护成本
三个闭包的内存开销
让代码可读性下降一半

2026年的写法：

jsx 复制代码

function UserList({ users, filter }) {
  const sorted = users
    .filter(u => u.name.includes(filter))
    .sort((a, b) => a.name.localeCompare(b.name));

  const stats = {
    total: sorted.length,
    active: sorted.filter(u => u.active).length,
  };

  return <div>{/* ... */}</div>;
}

干净、直接、编译器自动优化。

唯一例外： 如果你的计算确实很重（比如对10万条数据做复杂聚合），并且你能用React DevTools Profiler证明它是瓶颈------那保留useMemo。但99%的场景不是这样。

反模式2：useCallback包裹所有传给子组件的函数

jsx 复制代码

function Dashboard() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    setCount(c => c + 1);
  }, []);

  const handleReset = useCallback(() => {
    setCount(0);
  }, []);

  const handleExport = useCallback(() => {
    exportData(count);
  }, [count]);

  return (
    <>
      <Button onClick={handleClick} />
      <Button onClick={handleReset} />
      <ExportButton onClick={handleExport} />
    </>
  );
}

这段代码有三个问题：

useCallback本身不阻止子组件重渲染 ------除非子组件用了React.memo
没有React.memo的情况下，useCallback做的事就是"稳定引用"------但React Compiler已经能自动判断哪些组件需要跳过
handleExport的依赖数组里有count，每次count变化它都会重建------useCallback完全没起作用

更直接的问题是：AI工具特别爱生成useCallback。 因为训练数据里大量"React性能优化最佳实践"文章都在教"传给子组件的函数一定要useCallback"。这个建议在2023年可能有道理，在2026年就是噪音。

2026年的写法：

jsx 复制代码

function Dashboard() {
  const [count, setCount] = useState(0);

  return (
    <>
      <Button onClick={() => setCount(c => c + 1)} />
      <Button onClick={() => setCount(0)} />
      <ExportButton onClick={() => exportData(count)} />
    </>
  );
}

反模式3：React.memo包裹每个导出组件

jsx 复制代码

const UserCard = React.memo(function UserCard({ user, onSelect }) {
  return (
    <div onClick={() => onSelect(user.id)}>
      <Avatar src={user.avatar} />
      <span>{user.name}</span>
    </div>
  );
});

React.memo的逻辑是：props没变就跳过渲染。问题是：

React Compiler已经在做同样的事，而且粒度更细------它可以跳过组件内部的部分表达式，不需要跳过整个组件
React.memo每次渲染都要做props浅比较------如果props经常变，这个比较本身就是白白浪费
和useCallback配套才有意义------但如果你已经不写useCallback了，React.memo也没必要了

一条很好判断的规则： 如果你的组件渲染成本低于props浅比较成本（大部分简单组件都是这样），React.memo就是负优化。

2026年的写法： 直接导出，不包裹。

jsx 复制代码

function UserCard({ user, onSelect }) {
  return (
    <div onClick={() => onSelect(user.id)}>
      <Avatar src={user.avatar} />
      <span>{user.name}</span>
    </div>
  );
}

反模式4：useEffect + useState做数据获取

这可能是最根深蒂固的反模式，也是AI生成代码最爱写的模式：

jsx 复制代码

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let cancelled = false;
    setLoading(true);
    
    fetchUser(userId)
      .then(data => {
        if (!cancelled) {
          setUser(data);
          setLoading(false);
        }
      })
      .catch(err => {
        if (!cancelled) {
          setError(err);
          setLoading(false);
        }
      });
    
    return () => { cancelled = true; };
  }, [userId]);

  if (loading) return <Spinner />;
  if (error) return <ErrorMessage error={error} />;
  return <div>{user.name}</div>;
}

25行代码做一件事：获取数据。 而且还有这些隐患：

问题	后果
竞态条件	userId快速变化时，旧请求覆盖新数据
瀑布请求	父组件获取完→子组件才开始获取→孙组件再等
无缓存	同一个userId每次挂载都重新请求
首次渲染闪白屏	loading状态永远要经历true→false
服务端渲染不友好	useEffect在SSR阶段不执行

2026年的写法（用TanStack Query）：

jsx 复制代码

function UserProfile({ userId }) {
  const { data: user, isPending, error } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetchUser(userId),
  });

  if (isPending) return <Spinner />;
  if (error) return <ErrorMessage error={error} />;
  return <div>{user.name}</div>;
}

或者用React 19的use：

jsx 复制代码

function UserProfile({ userPromise }) {
  const user = use(userPromise);
  return <div>{user.name}</div>;
}

从25行到3行。 自动处理竞态、缓存、去重、后台刷新。

这不是风格偏好，是架构级的差距。 useEffect做数据获取在React官方文档里已经被标注为不推荐。

反模式5：过度拆分组件"优化性能"

我见过的一个极端案例：一个表单页面被拆成了47个组件------每个输入框一个组件、每个标签一个组件、每个校验提示一个组件。理由是"避免整个表单重渲染"。

这是对React渲染机制的误解。

组件拆分不等于性能优化。每多一个组件，React就多了：

一次reconciliation比较
一个Fiber节点
一次props序列化和比较

合理的拆分标准应该是：

场景	该拆	不该拆
组件超过200行	✅ 可维护性	-
需要独立复用	✅ 复用性	-
有独立的状态逻辑	✅ 关注点分离	-
"这一块可能会频繁更新"	❌ 过早优化	✅ 让Compiler处理
"拆小一点性能好"	❌ 错误假设	✅ 用Profiler验证

真正该做的性能优化是状态下沉（state co-location）： 把state放到真正需要它的组件里，而不是提升到父组件然后靠拆分来避免重渲染。

jsx 复制代码

// ❌ 状态提升 + 过度拆分
function Form() {
  const [name, setName] = useState('');
  const [email, setEmail] = useState('');
  return (
    <>
      <NameInput value={name} onChange={setName} />
      <EmailInput value={email} onChange={setEmail} />
    </>
  );
}

// ✅ 状态下沉，各管各的
function Form() {
  return (
    <>
      <NameInput />
      <EmailInput />
    </>
  );
}

function NameInput() {
  const [name, setName] = useState('');
  return <input value={name} onChange={e => setName(e.target.value)} />;
}

速查表：2026年React性能优化决策

以前的"最佳实践"	2026年的做法	什么时候还需要旧写法
useMemo包裹计算	直接写，Compiler处理	10万+数据量的复杂聚合，且Profiler证实是瓶颈
useCallback包裹函数	直接内联	传给第三方库且该库依赖引用稳定性
React.memo包裹组件	直接导出	极重的渲染组件（Canvas/3D），且Profiler证实
useEffect获取数据	TanStack Query / use() / SWR	永远不需要（没有例外）
过度拆分组件	按逻辑拆分 + 状态下沉	永远不需要（没有例外）
手动shouldComponentUpdate	删掉	2026年了不应该还有Class组件

判断标准就一条：先用React DevTools Profiler跑一遍。没有证据证明是瓶颈的，就别优化。

升级React Compiler的最小步骤

如果你的项目还没启用React Compiler：

bash 复制代码

npm install react-compiler-runtime
npm install -D babel-plugin-react-compiler

Babel配置加一行：

json 复制代码

{
  "plugins": [
    ["babel-plugin-react-compiler", {}]
  ]
}

Vite用户：

js 复制代码

// vite.config.js
import { reactCompiler } from 'react-compiler-runtime/vite';

export default {
  plugins: [reactCompiler()],
};

启用后，可以逐步删掉不必要的useMemo/useCallback/React.memo。不用一次性全删------编译器和手动优化可以共存，只是手动的部分变成了冗余代码。

别让AI替你做决定

这篇文章本质上在说一件事：不要因为AI生成了useMemo，你就不敢删它。

AI代码生成器的训练数据里充满了2020-2024年的"最佳实践"文章。那些文章在当时是对的------React没有编译器，手动memoization是唯一选择。但2026年了，工具变了，实践也要变。

用AI写代码没问题。但Review的时候，你需要知道什么该留、什么该删。

你的项目升级React Compiler了吗？升级后删了多少行useMemo？评论区聊聊。