各位前端界的同仁们，大家晚上好！
欢迎来到本次关于“React 编译器与手动 useMemo 的爱恨情仇”的深度技术讲座。我是你们今天的讲师，一个在 React 的世界里摸爬滚打多年，见证过从 jQuery 到 Vue 再到 React 全家桶变迁的“老司机”。
今天我们要聊的话题非常刺激，甚至可以说是“颠覆三观”。在座的各位，有多少人写过这样的代码：
// 这是一个经典的“过度优化”样本
function MyExpensiveComponent({ data }) {
const memoizedData = useMemo(() => {
return processData(data);
}, [data]);
const memoizedHandler = useCallback(() => {
console.log("I am being called");
}, []);
return (
<div>
<MemoizedChild data={memoizedData} onClick={memoizedHandler} />
</div>
);
}如果你举手了，请不要害羞，把手放下来，深呼吸。我知道，我也经历过。我们总是担心 React 的渲染机制不够聪明，担心父组件一变，子组件就跟着“抽风”，于是我们拿起了 useMemo 和 useCallback 这两把大锤，试图把 React 的大脑砸开，强行让它按照我们的意愿去工作。
但是，今天我要告诉大家一个坏消息，也是一个好消息：React 19 带来的“编译器”（代号 Forget）可能要终结我们这种“手动调优”的苦行了。
在这个讲座里，我们将深入探讨 React Compiler 是如何像一位超级保姆一样，接管我们原本繁琐的优化工作，以及在这个过程中，我们该如何调整心态，从“过度优化者”进化为“声明式编程大师”。
第一部分：手动优化的“巴别塔”与“意大利面条”
首先，让我们来盘一盘我们为什么要手动优化。
在 React 的早期岁月，或者说在“社区共识”形成之前，我们写代码是这样的：防御性编程。
我们害怕什么？我们害怕 React 的渲染是“原子性”的，害怕父组件传下来的 props 变了一个微小的属性，导致子组件重新渲染整个树。于是，我们发明了 useMemo。
useMemo 的初衷是好的：“嘿，React，如果这个输入没变，你就别给我重新算这个结果了，把旧的那个给我。”
这听起来很完美，对吧？但现实往往比代码复杂得多。
1.1 依赖地狱
让我们来看一个稍微复杂一点的场景。假设我们有一个仪表盘组件，里面需要计算各种指标，还要渲染一个图表。
function Dashboard({ user, settings }) {
// 1. 计算：根据用户和设置计算一些数据
const metrics = useMemo(() => {
console.log("Calculating metrics...");
return {
total: user.points * settings.multiplier,
level: calculateLevel(user.points)
};
}, [user, settings]);
// 2. 排序：根据设置对列表排序
const sortedList = useMemo(() => {
console.log("Sorting list...");
return items.sort((a, b) => a[settings.sortBy] - b[settings.sortBy]);
}, [items, settings.sortBy]);
// 3. 格式化：把数据变成字符串
const formattedText = useMemo(() => {
console.log("Formatting text...");
return JSON.stringify(metrics);
}, [metrics]);
// 4. 处理函数：一个点击事件
const handleClick = useCallback(() => {
alert(formattedText);
}, [formattedText]);
return (
<div>
<h1>Hello, {user.name}</h1>
<button onClick={handleClick}>Check Data</button>
<Chart data={sortedList} />
</div>
);
}请看这段代码。它看起来很整洁，对吧？但实际上，它充满了“谎言”和“猜测”。
我们告诉 React：“嘿，metrics 依赖于 user 和 settings，所以只有这两个变了，你才重新算。”
但是，items 变了怎么办？React 不知道！React 不懂业务逻辑。它只知道你在 useMemo 里面用了 items，但你没把它写进依赖数组里。
于是，Bug 诞生了。
如果你不小心修改了 items 而忘了把 items 加进依赖数组，React 就会继续使用旧的 metrics。你的图表数据可能是旧的，你的文本显示可能是错的，而 React 还在角落里开心地笑，因为它觉得“一切正常”。
这就是手动 useMemo 的痛点：维护成本极高，且极易引入难以追踪的 Bug。 我们在写代码的时候，就像是在玩俄罗斯方块，不仅要堆砌代码，还要时刻盯着那个依赖数组，生怕漏掉一个变量。
1.2 递归优化的荒谬
为了解决这个问题，我们往往陷入了“递归优化”的深渊。
为了防止 metrics 变化导致子组件重渲染，我们可能会把 metrics 用 useMemo 包一下；为了防止 sortedList 变化导致图表组件重渲染，我们可能又要把 sortedList 用 useMemo 包一下。
代码变成了这样：
function Dashboard({ user, settings }) {
// ... 计算逻辑 ...
const sortedList = useMemo(() => {
return items.sort(...);
}, [items, settings.sortBy]);
// 甚至，为了防止 sortedList 对象引用变化，我们还要再包一层？
const stableSortedList = useMemo(() => {
return { ...sortedList }; // 浅拷贝，为了引用稳定
}, [sortedList]);
return <Chart data={stableSortedList} />;
}这太荒谬了！我们写代码是为了表达“意图”，而不是为了“欺骗”编译器。手动优化往往让代码变得晦涩难懂，让阅读代码的人（包括三个月后的你自己）感到头皮发麻。
第二部分：编译器来了，它叫“Forget”
就在我们还在纠结依赖数组的时候，React 团队悄悄地推出了一款名为“Forget”的编译器。它不是运行时的库，也不是一个新的 Hook，而是一个在构建阶段运行的代码转换器。
它的核心思想非常简单，甚至有点反直觉：“相信 React，相信你的代码是纯函数。”
2.1 什么是“纯函数”？
在数学里，纯函数意味着：给定相同的输入，永远得到相同的输出，且不产生副作用。
在 React 中，这意味着：渲染函数不应该修改状态，不应该发起网络请求，不应该改变 DOM。
React Compiler 拿到你的组件代码后，会进行一番“扫描”。它会问自己：“嘿，这段代码里有没有副作用？”
- 如果没有副作用： Compiler 就会介入。它会分析代码的依赖关系。如果它发现
metrics的计算依赖于user和settings，那么它会自动生成类似useMemo的代码，但它是自动的，且绝对正确的。 - 如果有副作用： Compiler 就会退后一步，放行。它知道它搞不定副作用，所以它会尊重你的手动控制。
2.2 编译器视角下的代码
让我们看看同样的 Dashboard 组件，在编译器眼中会变成什么样。
编译前（开发者手写）：
function Dashboard({ user, settings }) {
const metrics = useMemo(() => {
return {
total: user.points * settings.multiplier,
level: calculateLevel(user.points)
};
}, [user, settings]);
return <div>{metrics.total}</div>;
}编译后（React 内部看到的）：
实际上，React 19 内部会自动插入优化逻辑。对于开发者来说，你写的代码完全不需要改变！
你不需要写 useMemo，也不需要写 useCallback。你只需要像以前一样写声明式代码。
function Dashboard({ user, settings }) {
// 编译器自动帮你做了优化，你甚至不需要知道它发生了
const metrics = {
total: user.points * settings.multiplier,
level: calculateLevel(user.points)
};
return <div>{metrics.total}</div>;
}看懂了吗？
编译器会自动识别 metrics 依赖于 user 和 settings。当这两个变量没变的时候，React 会直接从内存中把 metrics 的旧值拿出来给你用，完全不会重新执行那行计算代码。当变量变了，它才会重新计算。
这就像是你雇了一个超级实习生。以前你自己算，还要担心算错了；现在你雇了这个实习生，你只管说“我要算这个”，剩下的交给实习生。实习生不仅算得快，而且绝对不会偷懒（除非你让他去干副作用的事）。
第三部分：实战演练——手动 vs 自动
为了让大家更直观地感受这种变化，我们来做一个实战对比。
场景：一个复杂的列表过滤与排序组件
我们需要一个组件，它接收一个巨大的数组 rawData 和一个过滤条件 filter。我们需要对数据进行过滤，然后排序，最后渲染。
方案 A：手动优化（过去式）
import React, { useMemo, useCallback } from 'react';
const FilterableList = React.memo(({ rawData, filter }) => {
// 1. 过滤
const filteredData = useMemo(() => {
console.log("Filtering...");
return rawData.filter(item => item.category === filter.category);
}, [rawData, filter.category]);
// 2. 排序
const sortedData = useMemo(() => {
console.log("Sorting...");
return filteredData.sort((a, b) => a.name.localeCompare(b.name));
}, [filteredData]);
// 3. 处理点击
const handleItemClick = useCallback((id) => {
console.log("Clicked:", id);
}, []);
return (
<ul>
{sortedData.map(item => (
<li key={item.id} onClick={() => handleItemClick(item.id)}>
{item.name}
</li>
))}
</ul>
);
});
export default FilterableList;分析：
这段代码非常标准，也非常“安全”。但是，它有一个致命的弱点：复杂度随数据量线性增长。如果 rawData 有 10,000 条数据，每次 filter.category 变化，你都要重新遍历 10,000 条数据去过滤，然后再排序。
而且，sortedData 依赖 filteredData，这又增加了一层嵌套的依赖追踪。
方案 B：编译器优化（未来式）
// 注意：这里不需要 React.memo，也不需要 useMemo
// 只要没有副作用，编译器全管！
const FilterableList = ({ rawData, filter }) => {
// 编译器会自动分析：sortedData 依赖于 rawData 和 filter.category
// 并且它知道 filteredData 只是中间变量，可以优化掉
const filteredData = rawData.filter(item => item.category === filter.category);
const sortedData = filteredData.sort((a, b) => a.name.localeCompare(b.name));
const handleItemClick = (id) => {
console.log("Clicked:", id);
};
return (
<ul>
{sortedData.map(item => (
<li key={item.id} onClick={() => handleItemClick(item.id)}>
{item.name}
</li>
))}
</ul>
);
};发生了什么？
- 没有
useMemo： 代码清爽了，没有那些令人心烦的依赖数组[rawData, filter.category]。 - 没有
React.memo： 因为我们知道只有当rawData或filter变化时，这个组件才会重渲染。编译器帮我们做了记忆化，我们不需要手动做。 - 性能： 编译器会生成非常高效的代码。它会检测到
filter.category是稳定的，所以它甚至可能完全跳过filter逻辑，直接返回上一次的sortedData。
这不仅仅是少写了两行代码，这改变了我们思考问题的方式！
以前我们想的是：“我怎么才能让这个组件不重渲染？”
现在我们想的是：“这个组件的逻辑是什么？”
第四部分：编译器的边界——副作用与“不纯”代码
虽然编译器很强大，但它不是魔法。它有一个非常明确的边界：纯函数。
React Compiler 的核心逻辑是基于“依赖图”的。它追踪一个变量是在哪里被读取的。如果它发现这个变量被读取了，它就会认为这个变量是“活跃”的。
如果变量是活跃的，React 必须确保它在渲染时是最新的。
4.1 副作用的禁区
这是编译器最严格的地方。如果你在渲染函数里做了副作用，编译器会直接报错。
function BadComponent() {
const [count, setCount] = useState(0);
// 错误！这行代码在渲染期间执行了副作用
// 编译器会大喊：Stop! You are mutating the render!
document.title = `Count is ${count}`;
return <button onClick={() => setCount(count + 1)}>Count: {count}</button>;
}在 React 18 及之前，这虽然允许（虽然不推荐），但编译器会直接拒绝编译这段代码。它强制要求开发者将副作用剥离到 useEffect 中。
这其实是一件好事。它逼迫我们写出更纯粹的组件。
4.2 何时我们需要手动优化？
既然编译器这么强，我们是不是再也不需要 useMemo 了？
答案是：不是，但极少。
编译器擅长处理“计算”和“结构化”，但不擅长处理“昂贵的计算”和“引用稳定性”。
场景 1：昂贵的计算
假设我们有一个函数，计算一个数字的质因数分解。这是一个 $O(N)$ 的操作，如果输入是 largeNumber，计算量很大。
function PrimeFactors({ largeNumber }) {
// 编译器会自动缓存这个结果吗？
// 理论上会。如果 largeNumber 没变，它就不算。
const factors = getPrimeFactors(largeNumber); // 假设这是一个很慢的函数
return <div>Factors: {factors.join(', ')}</div>;
}编译器确实会缓存这个结果。但是，如果 largeNumber 每次都变，编译器依然会每次都调用 getPrimeFactors。
如果你发现，即便 largeNumber 变了，你也想跳过计算（比如你只想在用户点击按钮时才计算），那么你就需要手动写 useMemo 来控制计算的时机。
场景 2：引用稳定性
这是编译器最“头疼”的地方。
假设我们有一个子组件 Child，它接收一个函数作为 prop。
function Parent() {
const [count, setCount] = useState(0);
// 这个函数每次渲染都会创建一个新的引用
const handleClick = () => {
setCount(count + 1);
};
return <Child onClick={handleClick} />;
}在 React 18 之前，为了防止 Parent 重渲染导致 Child 重渲染，我们必须用 useCallback 包一下 handleClick。
但在 React Compiler 时代，情况变得有趣了。
如果 Child 是一个纯组件（它只依赖 onClick），并且 onClick 每次都是新的函数引用，那么 Child 每次都会重渲染。
编译器能解决吗？编译器可以缓存 handleClick 的值，但这只是治标不治本。真正的问题是：我们需要重新渲染吗？
如果 Child 内部没有使用 count，那么 Parent 重渲染完全是浪费。编译器会分析 Child 的代码，发现它只用了 onClick。如果它发现 onClick 的变化没有导致任何可见的 UI 变化（因为 Child 内部逻辑没变），它可能会选择不重新渲染 Child。
这叫 “子树优化”。
但如果你有多个子组件，或者逻辑非常复杂，编译器可能无法完全预测。在这种情况下，手动使用 useCallback 依然有其价值，它就像一个“保险丝”，明确告诉 React：“嘿，这个函数变了，请确保依赖它的组件知道。”
第五部分：认知的重构——从“如何做”到“做什么”
这是本次讲座最重要的部分。
在手动优化的时代，我们的思维模式是“过程导向”的。我们关心的是：如何避免重渲染？如何缓存数据？如何传递回调？
这种思维模式让我们写出了很多“防御性”代码。我们害怕出错，所以到处加锁。
而在 React Compiler 时代，我们的思维模式应该转变为“声明式”的。
你不需要关心 React 怎么渲染，你只需要关心“当输入改变时，UI 应该呈现什么状态”。
5.1 代码即文档
试想一下，如果你读一个没有 useMemo 的代码，你会看到清晰的逻辑流：
- 获取数据。
- 过滤数据。
- 排序数据。
- 渲染列表。
这读起来非常顺畅，就像读散文一样。
如果你读一个充满了 useMemo 和 useCallback 的代码，你看到的是：
- 定义变量 A。
- 定义变量 B。
- 定义变量 C。
- 定义函数 D。
- … 一堆依赖数组 …
你读代码的时候，不得不停下来思考：“哦，变量 B 依赖于 A，所以 A 变了 B 也会变。但 C 依赖于 B，所以 B 变了 C 也会变。但是 A 变了，C 会变吗？等等，C 的依赖数组里没写 A？”
这种认知负担是巨大的。
编译器把这种负担从开发者转移到了编译器身上。开发者只需要写出最自然、最符合业务逻辑的代码。编译器会去处理那些枯燥的、重复的、容易出错的优化工作。
5.2 “懒惰”的美德
在 React Compiler 时代，“懒惰”是一种美德。
不要急于计算。不要急于渲染。让编译器去决定什么时候做这些事情。如果你的代码写得好，编译器会帮你“偷懒”，只在你真正需要的时候才工作。
第六部分：总结与展望
各位，让我们回顾一下。
我们曾经为了性能，在代码里编织了一张巨大的网，用 useMemo、useCallback、React.memo 把自己缠得透不过气。我们担心依赖数组，担心引用泄漏，担心性能下降。
现在，React Compiler 像一把锋利的剪刀，剪断了这些无用的线头。
它让我们回到了 React 的初心：声明式 UI。
它告诉我们：相信你的代码。 只要你的代码是纯的，React 就会善待它。
当然，这并不意味着我们彻底告别了 useMemo。在处理极度昂贵的计算或极其复杂的引用依赖时，手动优化依然有其用武之地。但它不再是我们日常开发的主力军，而更像是一个应对极端情况的“急救包”。
未来的前端开发，可能不再需要我们在渲染函数里绞尽脑汁地写优化代码。我们将有更多的时间去思考业务逻辑，去设计更好的架构，去写更易读的代码。
这难道不是我们梦寐以求的吗？
最后，我想送给大家一句话：
“不要为了优化而优化。让你的代码表达意图，让编译器帮你实现细节。”
谢谢大家！希望这篇讲座能让你对 React Compiler 有一个新的认识。让我们拥抱变化，一起迈向更纯净的 React 代码世界吧！