女士们，先生们，欢迎来到 React 的“深水区”。
今天我们要聊的话题，稍微有点……呃，硬核。这就像是你在餐厅点了“最便宜的牛排套餐”，结果端上来的是“分子料理”，而且厨师还告诉你：“别担心，我加了点‘自动优化’的酱汁，保证你吃的时候觉得这是米其林三星。”
我们要聊的是 React 自动 Memoization，以及那个传说中的 React Compiler。这玩意儿就像是一个过度热情、有点多管闲事，但本质上是个好人的家庭管家。
在这场关于“编译器推导依赖”与“开发者预期不符”的冲突中，React 到底是如何“降级”并解决问题的？别眨眼，我们要开始扒开 React 的裤衩（比喻义），看看里面的弹簧和齿轮是如何运作的。
第一部分：编译器，那个懒惰的神
首先，让我们来认识一下这个新来的“实习生”。React Compiler（或者说自动 Memoization 机制）的核心哲学是：“我不做重复的事情。”
在以前，如果你想告诉 React “嘿，这个函数在 a 变化时才需要重新计算”，你得自己写 useMemo(() => { ... }, [a])。这就像是你在告诉厨师：“只有当番茄新鲜的时候，我才切番茄。”
但是，编译器是个懒鬼。它觉得：“切番茄？为什么要切？直接把生的番茄端上来不就行了？除非……除非我发现盘子里的肉已经凉了（依赖变化了）。”
编译器的工作原理非常简单粗暴，它就像个拿着放大镜的安检员，盯着你的代码 AST（抽象语法树）。它扫描你的函数，看它到底“吃”了哪些变量。如果它发现你的函数只用了 a 和 b，它就会自动给你加上 [a, b]。
这听起来很完美，对吧？零成本抽象。你不再需要操心依赖数组了。
第二部分：当魔法失效——冲突的产生
然而，现实往往是残酷的。编译器虽然聪明，但它有时候也是个“读不懂空气”的机器。当它推导出的依赖，和你脑子里的那个“预期”对不上号时，冲突就发生了。
这里有三种最经典的“车祸现场”：
场景一：显式声明的傲慢
你是个老派的 React 开发者。你觉得自己很懂。你在代码里写了 useMemo，并且明确声明了依赖。
function Counter({ count }) {
// 老派写法：显式声明依赖
const doubled = useMemo(() => {
console.log("计算中...");
return count * 2;
}, [count]);
return <div>{doubled}</div>;
}编译器扫过这段代码，心想：“哼，这个家伙写了 useMemo，那肯定是有原因的。虽然他写了 [count]，但我编译器更厉害，我也能推导出来。”
于是，编译器决定接管控制权。它发现函数体里确实只用了 count，所以它决定绕过你手写的 useMemo，直接帮你做优化。
冲突点： 开发者预期：“我要手动控制这个计算，我要在 count 变化时才执行。”
编译器行为： “我知道你想要这个，但我决定更早一点执行（或者更聪明地执行）。”
结果： 你的手动 useMemo 完全失效了。这就是所谓的“降级策略”中的第一种：显式声明失效。
场景二：闭包的幽灵
这是最坑爹的地方。编译器是基于静态分析的，它看的是代码的“骨架”。但是，闭包是代码的“灵魂”，灵魂是飘忽不定的。
function BadComponent() {
const [count, setCount] = useState(0);
// 你以为这个函数依赖了 count
const handleClick = () => {
console.log(count);
};
// 但编译器可能认为它不需要依赖 count
return <button onClick={handleClick}>Click me</button>;
}如果你在 handleClick 里只读取了 count，编译器会把它加进依赖里。但如果 handleClick 被传递给一个子组件，而子组件没有使用它，编译器可能会想：“哦，这个函数没被用到，那我把它当成纯函数处理吧。”
冲突点： 开发者预期：“这个函数依赖了 count，每次渲染都要用最新的 count。”
编译器行为： “这个函数看起来好像依赖了 count，但既然没人调用它，我就把它当常量处理。”
结果： 点击按钮，console.log 打印的是 0（旧的值），而不是你期望的 1。这就是经典的闭包陷阱，编译器有时候也会掉进坑里。
场景三：循环中的变量
function List() {
const items = ["A", "B", "C"];
return (
<ul>
{items.map((item, index) => (
<li key={index}>
<MemoizedItem data={item} />
</li>
))}
</ul>
);
}
// 编译器看到：MemoizedItem 只读取了 'item'，没读 'index'。
// 它决定：只把 'item' 加入依赖。这看起来没问题，对吧？但如果 MemoizedItem 的内部逻辑其实隐式依赖了 index（比如通过 useRef 或者某种奇怪的副作用），编译器就会漏掉这个依赖。
第三部分：底层降级策略——React 的急救包
当编译器的“自动推导”和开发者的“手动预期”打架时，React 不会直接把你的屏幕炸了。它启动了一套精密的降级策略。简单来说，就是当编译器发现“搞不定”或者“你不答应”的时候，它会乖乖退回到旧时代，或者采取特殊手段来妥协。
策略一：显式屏障
这是最直接的武器。如果你真的想让 React 听你的，你就得用 useMemo 或 useCallback 来筑起一道墙。
React Compiler 的核心逻辑里有一条铁律：如果一个组件使用了 useMemo 或 useCallback，编译器就会“停止工作”，把这个组件完全交给手动控制。
function MyComponent() {
const [count, setCount] = useState(0);
// 这是一道墙。编译器看到这里，就会说：“好吧，这哥们儿不想让我管，我退下。”
const expensiveValue = useMemo(() => {
return count * 2;
}, [count]);
return <div>{expensiveValue}</div>;
}降级效果： 编译器完全放弃对该组件的自动优化。React 会严格按照你手写的依赖数组来决定是否重新计算。这是开发者对编译器最有力的反击。
策略二：useRef——我不变，但我变
useRef 是 React 里最被低估的工具，也是解决冲突的神器。它的特性是：在渲染之间保持同一个引用（对象），但内容可以变。
假设编译器把你的函数搞乱了，你想让一个变量在渲染时“假装”没变，或者你想绕过编译器的依赖推导：
function MyComponent() {
const [count, setCount] = useState(0);
// 我们用 ref 存储最新的 count
const countRef = useRef(0);
countRef.current = count;
// 这个函数虽然依赖了 count，但编译器可能会认为它没依赖
// 我们强制使用 ref 来获取最新值，绕过编译器的推导
const handleClick = () => {
console.log(countRef.current); // 永远是最新值
};
return <button onClick={handleClick}>Click</button>;
}降级效果： 这种模式本质上是在告诉 React：“这个变量虽然名字叫 count，但我通过 ref 管理它。编译器，你别管它了，我只在需要的时候手动去读。”
策略三：useEffect——延迟满足
有时候，你不需要在渲染时计算结果，你只需要在渲染之后计算结果。这时候，useEffect 就成了完美的避难所。
编译器主要优化的是渲染阶段（Render Phase）。如果你把计算逻辑扔到 useEffect 里，编译器就完全无法触及它。
function MyComponent() {
const [data, setData] = useState(null);
// 编译器：我看不见这里，这里不在渲染里。
useEffect(() => {
if (!data) return;
const expensiveResult = heavyComputation(data);
console.log(expensiveResult);
}, [data]);
return <button onClick={() => setData("something")}>Load Data</button>;
}降级效果： 这是一种“降级”吗？某种程度上是。你牺牲了“渲染时计算”的性能，换取了“编译器完全不管”的确定性。这在处理非常复杂的依赖关系时非常有用。
第四部分：深入机制——编译器是如何“认怂”的？
现在，让我们深入 React 的源码逻辑，看看当冲突发生时，到底发生了什么。这就像是在看后台的日志。
React Compiler 在处理代码时，会进行“静态分析”。它会尝试构建一个“快照”。这个快照包含了组件在当前渲染周期内读取了哪些变量。
1. 检测到“不稳定”代码：
如果你的代码里包含以下任何一种“魔法”，编译器就会立刻警觉：“这玩意儿不纯！”
useState,useReducer,useContext,useRef,useMemo,useCallback,useEffect,useLayoutEffect,useTransition,useDeferredValue,useId,useDebugValue。
2. 自动降级：
一旦检测到这些钩子，React 会立即停止编译优化，退回到传统的手动 Memoization 模式。
// 伪代码逻辑
function compileReactCode(code) {
const unstableHooks = ['useState', 'useEffect', ...];
if (containsUnstableHooks(code)) {
console.log("检测到不稳定代码，降级为手动模式");
return fallbackToManualMemoization(code);
}
return autoMemoize(code);
}3. 依赖冲突的最终裁决：
如果编译器推导出的依赖，与你手写的 useMemo 依赖数组不一致，React 会发生以下情况：
- 编译器优先（默认）： React 会忽略你的手动依赖数组，完全信任编译器的推导。这可能会导致你写的手动
useMemo失效，就像我们之前说的。 - 显式声明优先（如果开启了严格模式？）： 实际上，目前的 React Compiler 规则是：显式的
useMemo会覆盖编译器的推导。
这意味着，如果你写了 useMemo(() => ..., [a, b])，编译器会看到 useMemo 这个“障碍”，然后绕过它。它不会重新计算你的依赖数组，而是直接把你手动写的数组扔给 React 的渲染管线。
第五部分：实战演练——如何应对这种混乱
作为一名资深开发者，面对编译器的“霸道”，我们不能只有抱怨。我们需要战术。
战术 1：拥抱 skip
React 团队最近引入了 skip 关键字。这就像是给编译器发了一张“免死金牌”。
如果你知道某个组件极其稳定，完全不会因为 props 的变化而改变行为，你可以告诉编译器：
function StaticComponent({ title }) {
// 告诉编译器：“兄弟，这玩意儿我看过，它只读 title，但我发誓它不会变，别瞎操心。”
skip(() => {
console.log("这个组件是静态的，别优化了");
});
return <h1>{title}</h1>;
}降级效果： skip 块内的代码会被编译器视为“非静态”，从而触发降级策略，防止编译器过度优化导致的问题。
战术 2：重构为纯函数
很多时候，冲突是因为函数太“脏”了。它既依赖了 props，又依赖了闭包里的变量，还调用了外部 API。
降级策略： 把这个函数拆分。
- 把纯计算逻辑提取出来。
- 把副作用（API 调用）放在
useEffect里。
// 好的做法
function GoodComponent() {
const [input, setInput] = useState("");
// 纯函数，编译器爱怎么优化怎么优化
const filteredData = useMemo(() => {
return data.filter(item => item.name.includes(input));
}, [data, input]);
// 副作用，编译器管不着
useEffect(() => {
fetchData(input);
}, [input]);
return <div>{filteredData}</div>;
}战术 3：理解 useEffect 的“降级”属性
还记得我说过 useEffect 是个避难所吗？在 React 19 的编译器逻辑中，如果你在组件顶层（非函数体内）写 useEffect，编译器会非常小心。
但是，如果你在 useEffect 里使用了 useState 的值，编译器可能会认为这个 useState 的值是“不稳定的”，从而触发降级。
function Example() {
const [count, setCount] = useState(0);
// 这里有一个微妙的陷阱
// 如果你在 useEffect 里读取了 count，编译器可能会因为“依赖了状态”而认为这个组件是“不稳定的”。
// 这会导致编译器放弃优化，退回到手动模式。
useEffect(() => {
console.log(count);
}, []);
return <button onClick={() => setCount(c => c + 1)}>Add</button>;
}解释： 虽然这里没有依赖数组，但编译器看到 useEffect 里用了 count，它可能会想：“这个组件依赖了状态，状态是会变的，所以我不能把整个组件当成静态的。” 这实际上是一种防御性的降级。
第六部分：总结——在这个新时代生存
React 自动 Memoization 的引入，就像是一场革命。它试图消灭 useMemo 和 useCallback 这两个让无数开发者掉头发的工具。
但是，革命总是伴随着流血和冲突。
当编译器推导的依赖与你的预期不符时，React 的底层逻辑其实非常宽容。它有一套完整的降级策略：
- 显式屏障： 你写
useMemo，我就闭嘴。 - 状态检测： 你用
useState，我就停手。 - 延迟执行： 你用
useEffect，我就不管。
给各位的建议：
不要盲目地删除所有的 useMemo 和 useCallback。编译器很聪明，但它有时候会过度自信。
如果你发现性能出现了问题，或者逻辑出现了 Bug（比如闭包陷阱），请立刻祭出你的老武器：
- 把计算逻辑扔进
useEffect（延迟执行）。 - 使用
useRef来存储需要跨渲染保持的变量。 - 或者，干脆在组件顶部加一个显式的
useMemo，告诉编译器：“这是我的地盘，你退下。”
在这个自动与手动并存的时代，最好的策略不是盲目跟风，也不是固步自封，而是理解底层逻辑，并在需要的时候，优雅地接管控制权。
毕竟，代码是写给人看的，只是顺便给机器跑。如果机器（编译器）看不懂你的意图，那就让它退后一步，让你来掌舵。
谢谢大家。现在，去把你的 useCallback 删了吧，但也别删得太干净，万一……万一它还在为你挡子弹呢。