嘿，大家好！把手里的咖啡放一放，把那个让你抓耳挠腮的 useMemo 先扔到一边。今天我们要聊点硬核的，但我会尽量让它听起来像是在讲一个关于“代码里的猫和老鼠”的故事。
我们要聊的是 React 编译器。你可能听说过“React Forget”，那个号称能自动帮你把代码变成“魔法”的东西。它确实挺神，就像你刚买的新车，自动泊车功能让你觉得自己像个赛车手，但有时候你也会想：“这玩意儿到底是怎么知道我要干什么的？”
今天，我们就把那块黑布揭开，看看 React Forget 的脑子里到底在想什么。核心问题只有一个：变量作用域是如何决定 React Forget 能不能给你自动缓存边界的？
准备好了吗？让我们开始这场代码的侦探之旅。
第一章：变量是间谍，作用域是监狱
想象一下，你的组件就是一个大房间。在这个房间里，你定义了各种变量：count、user、那个长得像外星人一样的 config 对象。
在 React 里，每次渲染，这些东西都会被重新创建。但是，React Forget 想做的是：能不能别每次都重新创建？能不能把上次的直接拿过来用？
这就是“缓存边界”的概念。如果编译器确信某样东西在两次渲染之间没有变化，它就会把这个东西“冻结”在内存里，下次渲染直接复用。
但是，这里有个巨大的风险。如果这个变量“越狱”了呢？如果它飞出这个房间，去到了外面的大千世界（比如全局变量、父组件、或者某个遥远的 Ref 里），那它还能保证不变吗？
这就是“逃逸分析”。
React 编译器就像一个神经质的管家，它时刻盯着你定义的每一个变量。它的内心独白是这样的：
“嘿，这个
const name = 'Alice'看起来很安全，它没有逃出去，它就在我的眼皮子底下。我可以把它缓存起来。”“但是！这个
user对象……等等，它刚才是不是被传给了父组件？或者被存进了一个全局的store里？天哪，它逃逸了！我不能缓存它，万一外面的人改了它怎么办？我得重新生成一个。”
变量逃逸，就是指你的变量从组件的局部作用域跑到了组件外部。一旦变量逃逸，React Forget 就会立刻放弃对该变量的缓存优化。
那么，是什么决定了变量能不能逃逸？答案就是——作用域。
第二章：作用域的三个等级：安全屋、半开放区和全开放区
为了理解逃逸，我们得先搞清楚变量生活的“房子”。
1. 函数作用域（安全屋）
这是最安全的区域。当你在一个函数里定义一个变量，这个变量只能在这个函数里被访问。
function MyComponent() {
// 这里是安全屋
const localVar = "I am safe here";
return <div>{localVar}</div>;
}React Forget 看到这个，会非常高兴。这个变量没有逃逸，它被死死地锁在这个函数里。编译器会想：“这玩意儿每次渲染都是新的，而且它不出去乱跑。好，我把它缓存了！”
但是，注意这个“每次渲染都是新的”。即使它没逃逸，如果它的值每次都在变，编译器也没法缓存它。缓存的前提是：没逃逸 + 值不变。
2. 组件作用域（半开放区）
这有点像你的卧室。你在卧室里定义的东西，通常只有你自己（组件）能看见。
function MyComponent() {
// 这是在组件作用域
const componentVar = "I live in the component";
return <div>{componentVar}</div>;
}在 React 19 之前，组件作用域通常也是安全的。但是，React 19 的编译器引入了一些新的规则。如果你的组件变量被用作 key，或者被传递给子组件，编译器就会开始警惕。
如果这个变量被作为 key 传递给列表：
function MyComponent() {
const items = [{ id: 1 }, { id: 2 }];
// 注意这里！id 作为 key
return (
<ul>
{items.map(item => (
<li key={item.id}>{item.id}</li>
))}
</ul>
);
}React Forget 会想：“item.id 是组件作用域里的变量吗？是的。但是，它被用作 key 了。key 是个特殊的存在。如果 item.id 在两次渲染中指向了同一个对象引用，那还好。但如果 items 数组本身变了，哪怕只是引用变了，React 都需要重新渲染列表。所以，为了安全起见，编译器可能会放弃对这个特定变量逃逸的分析，或者要求你必须保证这个 id 的引用稳定性。”
3. 全局作用域（全开放区——监狱大门大开）
这是最糟糕的情况。
let globalState = 0;
function MyComponent() {
// 变量逃逸了！它住进了大马路
return <div>{globalState}</div>;
}React Forget 看到这行代码，大概会直接崩溃或者把头埋进沙子里。globalState 在任何地方都能被改写。组件里的一行代码，外面的黑客都能改。这种情况下，没有任何缓存是有效的。每次渲染，这个组件都必须重新读取 globalState。
第三章：闭包——那个最狡猾的越狱者
现在，我们来到了最有趣，也是最容易让开发者（和编译器）掉进坑里的地方：闭包。
闭包就像是一个带锁的保险箱。你把变量放进保险箱，然后把保险箱传给了一个函数。这个函数虽然在外面，但它能打开保险箱访问里面的变量。
在 React 中，这通常发生在 useEffect 或者 useMemo 里。
场景一：useEffect 里的陷阱
function Counter() {
const [count, setCount] = useState(0);
// 这里定义了一个函数
const handleClick = () => {
console.log(count);
};
useEffect(() => {
// 等等！`handleClick` 被放到了这里。
// 它捕获了 `count`。`count` 逃逸了吗？
document.addEventListener('click', handleClick);
return () => document.removeEventListener('click', handleClick);
}, []); // 依赖项是空数组
return <button onClick={() => setCount(c => c + 1)}>Count: {count}</button>;
}React Forget 在看这段代码时，会非常纠结。
它看到 handleClick 是在组件体里定义的（组件作用域）。但是，这个函数被 useEffect 捕获了。
React Forget 的内心独白：
“handleClick 逃逸了吗？是的！它逃到了 useEffect 的回调函数里。这意味着，如果组件重新渲染，handleClick 会被重新创建。如果它被重新创建，那么它捕获的 count 可能会变（虽然在这个例子里 count 是依赖项，但逻辑上它是个闭包）。”
因为 handleClick 逃逸了，React Forget 知道它不能被简单地缓存。但是，它能不能缓存 count 呢？
如果编译器试图缓存 count，它必须确保 useEffect 的回调函数里看到的 count 值和渲染时是一样的。如果渲染时 count 是 5，handleClick 捕获了 5。但是，如果渲染时 count 变成了 6，handleClick 就会变成捕获 6。这时候，如果你缓存了 count，就会导致 Bug。
结论： 只要有一个变量（比如 count）被闭包捕获并逃逸到了副作用中，React Forget 就会放弃对该变量的优化。它必须假设“外面的人可能改了它”。
场景二：useMemo 里的依赖地狱
function ExpensiveCalc() {
const [num, setNum] = useState(1);
// 每次渲染都会创建这个对象
const obj = { value: num * 2 };
// 我们用 useMemo 试图缓存它
const memoized = useMemo(() => {
return { value: num * 2 };
}, [num]);
return (
<div>
<button onClick={() => setNum(n => n + 1)}>Add</button>
<div>Direct: {obj.value}</div>
<div>Memoized: {memoized.value}</div>
</div>
);
}这里有个有趣的点。obj 没有逃逸，它就在组件里。但是，它每次都在变（因为 num 变了）。React Forget 会想：“这玩意儿没逃逸，但是它的值每次都变。我不缓存它，直接算了。”
那 memoized 呢？memoized 有逃逸吗？它只是被渲染出来。它看起来是安全的。但是，它的依赖项是 [num]。如果 num 变了，它就得重新算。
React Forget 看到这个，可能会直接把 memoized 的计算逻辑内联掉，因为它发现这比 useMemo 开销还小。或者，它发现 memoized 的值仅仅依赖于 num，而 num 本身就是组件的渲染状态，它可以直接在渲染阶段算出来，根本不需要缓存。
关键点： 如果一个变量没有逃逸，但它依赖于一个逃逸的变量（比如被闭包捕获的变量），那么它本身也会变得“不安全”，无法被缓存。
第四章：实战演练——当编译器“想多了”
让我们来个实战。假设我们写了一个列表组件，里面有个搜索框。
function SearchList() {
const [query, setQuery] = useState("");
const [items, setItems] = useState([{ id: 1, text: "Apple" }, { id: 2, text: "Banana" }]);
// 这是一个过滤函数，它逃逸了吗？
// 它在组件里定义，但被 map 用到了。
const filteredItems = items.filter(item => item.text.includes(query));
// 我们把过滤后的结果传给了子组件
return (
<div>
<input type="text" value={query} onChange={e => setQuery(e.target.value)} />
<ItemList list={filteredItems} />
</div>
);
}
function ItemList({ list }) {
return (
<ul>
{list.map(item => (
<li key={item.id}>{item.text}</li>
))}
</ul>
);
}React Forget 会怎么分析？
-
query和items：它们是状态，肯定每次都变。它们逃逸了吗？它们传给了ItemList，但是ItemList是个纯函数组件（假设它没有用useMemo）。只要ItemList的 props 变了，React 就会重新渲染它。所以，query和items没有被“永久性”逃逸，它们只是触发了一次子组件的更新。React Forget 可以安全地缓存ItemList的渲染结果，直到listprop 变化。 -
filteredItems：这是重点。这是一个计算出来的值。它逃逸了吗？它被传给了ItemList。React Forget 会想：“
filteredItems是一个新数组。如果query变了，这个数组就会变。如果这个数组变了，ItemList就需要重新渲染。所以，filteredItems是安全的。”但是！ 如果
ItemList里用了一些复杂的逻辑，或者它本身也有useMemo，情况就复杂了。如果
ItemList写成了这样：function ItemList({ list }) { const firstItem = list[0]; // 这是个局部变量，没逃逸 // 假设我们在这里有个 useEffect useEffect(() => { console.log("List changed!", list); }, [list]); return <ul>...</ul>; }React Forget 看到这里，会再次纠结。
list逃逸到了useEffect里。这意味着，只要list变了，useEffect就会运行。虽然这不会阻止渲染，但它会影响性能。编译器可能会警告：“嘿，你把list传到了useEffect里，这可能会导致一些不必要的副作用运行，或者让我没法完全优化。”
第五章：副作用与引用稳定性——逃逸的另一种形式
除了显式的变量传递，还有一种隐形的逃逸：副作用。
如果一个对象包含了副作用（比如一个定时器、一个 WebSocket 连接，或者一个订阅了外部数据的对象），React Forget 会把它视为“不纯”。
function BadComponent() {
const [data, setData] = useState(null);
// 这是一个包含副作用的对象
const subscription = {
subscribe: () => {
console.log("Subscribing...");
// 假设这里有个 setInterval
},
unsubscribe: () => {
console.log("Unsubscribing...");
}
};
useEffect(() => {
subscription.subscribe();
return () => subscription.unsubscribe();
}, []);
return <div>Check console</div>;
}React Forget 看到这个 subscription 对象，它会想：“这个对象每次渲染都会被重新创建。它逃逸了吗？它被 useEffect 捕获了。它有副作用。我不能缓存这个对象。我甚至不能缓存整个组件的渲染结果，因为副作用是必须执行的。”
这就是缓存边界的失败。 任何包含副作用的变量，都会切断逃逸分析的链条。
第六章：如何欺骗（或者说，正确引导）编译器
既然编译器这么挑剔，我们怎么写代码才能让它开心，从而获得性能优化呢？
技巧一：保持局部，不要传给副作用
如果你在组件里计算了一个复杂的对象，但只想用它来渲染 UI，千万不要把它传给 useEffect 或 useMemo（除非你真的需要）。
// 好的做法
function GoodComponent() {
const [query, setQuery] = useState("");
const items = /* ... filter ... */;
// items 只用来渲染，没有逃逸
return <ItemList list={items} />;
}
// 坏的做法
function BadComponent() {
const [query, setQuery] = useState("");
const items = /* ... filter ... */;
// items 逃逸到了 useEffect
useEffect(() => {
console.log("Current items:", items);
}, [items]);
return <ItemList list={items} />;
}技巧二：利用闭包来“锁住”变量
有时候，闭包虽然危险，但它也是一种保护机制。如果你想让某个变量在多次渲染中保持稳定，你可以把它“锁”在闭包里。
function StableClosure() {
let count = 0; // 注意：这是 var，不是 let/const。var 的作用域是函数级的。
const increment = () => {
count++;
console.log(count);
};
return <button onClick={increment}>Click</button>;
}React Forget 看到这个 count，它发现 count 是 var 定义的。这意味着它的生命周期跨越了多次渲染。它逃逸了吗？它逃到了 increment 函数里。但是，因为 increment 每次都被重新创建，React Forget 会认为 count 是 increment 的私有状态。
这种模式在 React 里通常被认为是反模式（因为会导致闭包陷阱），但在 React Forget 的逃逸分析眼里，这可能是一个“信号”：这个变量虽然逃逸了，但它被限制在一个特定函数的上下文中，且该函数每次都会重新创建，所以编译器可能更容易推断它的行为。
技巧三：使用 useRef 存储需要逃逸但不需要渲染的数据
如果你确实需要一个变量在渲染之间保持不变，但又不希望它触发重新渲染，把它放在 useRef 里。
function RefComponent() {
const countRef = useRef(0);
// countRef 逃逸了吗？它逃到了组件实例上。
// 但是，它不会触发渲染。
// React Forget 可以安全地缓存这个组件的渲染结果，因为 countRef 的变化不会导致 props 变化。
return <div>Count: {countRef.current}</div>;
}第七章：总结——编译器眼中的代码美学
好了，让我们稍微整理一下思路。
React Forget 的逃逸分析，本质上是在问一个问题：“这个变量在两次渲染之间，是否可能被外部环境修改？”
- 如果变量没有逃逸（在组件体或函数体内），且不依赖逃逸的变量，那么它就是安全的。编译器会把它缓存起来，作为渲染的基石。
- 如果变量逃逸了（传给了父组件、闭包、或副作用），那么它就是危险的。编译器必须假设它可能变了，从而放弃对该变量的缓存，或者要求你手动维护依赖关系。
作用域就是那个划定“监狱”和“公园”的边界。
- 函数作用域是单人牢房，最安全。
- 组件作用域是公寓，需要小心不要把东西扔出窗外。
- 全局作用域是公共广场，绝对不能把变量放在那里。
- 闭包是带锁的房间，虽然锁住了，但它还是出去了。
所以，下次当你看到 React 编译器报错，或者当你发现某个组件没有自动优化时，不要急着骂娘。试着去看看你的变量。问问它们：“嘿，你今天出去乱跑了吗？你看到外面有人改你了吗？”
如果你的变量都很乖，老实待在作用域里，React Forget 会像对待亲儿子一样对待它，给你带来极致的性能。如果你的变量是个皮猴，到处乱窜，那编译器也只能无奈地摇摇头，让你手动写点 useMemo 来保平安。
这就是变量作用域与 React Forget 缓存边界的故事。希望下次写代码时，你能听到代码里那些看不见的小人在窃窃私语，告诉你哪里是安全的，哪里是陷阱。
现在，去吧，写出那些“乖孩子”变量！