React 渲染过程中的引用透明性：探讨函数组件重新执行时局部变量的堆栈分配 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同学，大家晚上好！欢迎来到今天的“React 深度解剖课”。我是你们的讲师，今天我们不讲怎么写一个 Hello World，我们要讲的是那些让你深夜痛哭、让你对着屏幕怀疑人生的——“为什么我的代码明明改了，结果却是错的？”

今天我们要聊的主题非常硬核，也非常核心：React 渲染过程中的引用透明性：探讨函数组件重新执行时局部变量的堆栈分配。

听起来很高大上对吧？别怕，咱们用最通俗的大白话，把这事儿给你捋得明明白白。

第一幕：React 组件，到底是个什么东西？

首先，咱们得打破一个迷思。很多初学者，甚至是工作了两三年的老司机，总觉得 React 组件是什么“魔法盒子”。你往里面扔数据，它就会吐出 UI。

错！大错特错！

React 组件，本质上就是一个JavaScript 函数。

不信？你可以打开你的 App.js，删掉所有的 import，删掉 export default，然后在里面写一个最简单的函数：

function App() {
  return <div>Hello World</div>;
}

现在，把这个文件保存。然后你打开浏览器，神奇的事情发生了：页面显示出了 “Hello World”。

这说明什么？说明 React 根本不在乎你写的是 class 还是 function，它只在乎一件事：调用这个函数，拿到返回值，然后渲染出来。

既然是函数，那它就得遵循 JavaScript 的所有规则。这就引出了我们今天第一个核心概念：引用透明性。

什么是引用透明性？

数学是完美的。在数学里，f(x) 总是等于 y。如果你把 x 改了，y 就变；如果 x 没变，y 就不变。这就是引用透明性。

React 要求组件具备这种特性。这意味着，组件的输出（UI），完全取决于它的输入（Props 和 State）。

如果输入没变，输出绝对不能变。这听起来很简单，对吧？但是，React 的架构决定了，这个函数经常会被重新执行。

第二幕：React 是个强迫症，它喜欢反复执行你的代码

React 为什么这么喜欢反复执行你的组件函数？这就涉及到 React 的生命周期了。

想象一下，你的页面上有两个数字：count = 1 和 count = 2。你希望它们显示在屏幕上。

当你第一次加载页面，React 调用 App() 函数：

读取 count 是 1。
生成 <div>1</div> 的 JS 对象。
React 把这个对象交给浏览器，浏览器画出了 1。

这时候，用户点了一下按钮，React 把 count 更新成了 2。

React 怎么知道 UI 需要变？它又把 App() 函数重新执行了一遍。

读取 count 是 2。
生成 <div>2</div> 的 JS 对象。
React 发现新的对象和旧的 DOM 节点不一样，于是通知浏览器把 1 涂改成 2。

重点来了： 在 React 的世界里，函数组件的执行是瞬态的。它就像一个转瞬即逝的烟火。

每次渲染，函数都会从头开始跑。变量会被重新声明，逻辑会被重新跑一遍。

第三幕：局部变量的“堆栈分配”之谜

这就到了我们今天最核心的技术点：局部变量的堆栈分配。

在 JavaScript 中，我们在函数里定义的 let、const、var，它们去哪儿了？

很多人觉得，这些变量应该像对象一样，被“保存”下来，下次渲染还能用。绝对不是！

这些变量是在堆栈上分配的。

为了让你彻底理解，咱们得稍微深入一点点计算机原理，但我保证，我会用最搞笑的方式讲出来。

1. 堆栈：像是一个极速外卖配送员

想象一下，你有一个非常忙碌的外卖骑手（堆栈），他手里只有一块无限大的白板。

你写代码 const a = 1：

骑手来了。
他在白板上写了个 1。
骑手拿着这个 1，跑进你的函数里，用完之后，骑手立刻把白板擦干净，下次再来的时候，白板是全新的。

这就是局部变量在堆栈上的分配机制。

每次函数重新执行（每次渲染）：

系统会清空上一轮的所有局部变量。
重新分配内存空间。
重新赋值。

所以，如果你在函数里写：

function Counter() {
  const count = 0; // 每次 App 重新渲染，这里都会重新创建一个新的 0
  console.log(count);
  return <div>{count}</div>;
}

每次渲染，count 都是一个全新的数字 0。它和上一次渲染的 count 没有任何关系，它们住在不同的内存地址上。

2. 堆：像个记性不好的老管家

那对象呢？比如 { name: 'React' }。对象通常存储在堆上。堆上的东西比较重，移动起来慢，而且容易丢。

如果对象一直留在堆上，下次渲染还能用吗？不能！

因为在 React 的函数组件里，你并没有把这个对象存下来。你只是把它生成了，传给了 JSX，用完了，它就变成了垃圾（GC），等着被回收。

所以，在 React 渲染过程中，除了通过 useState 或 useReducer 存下来的状态，其他所有东西都是“一次性用品”。

第四幕：闭包陷阱——为什么你的 `useEffect` 捕捉不到最新的状态？

理解了“堆栈分配”和“引用透明性”，你就能解释为什么会出现那个经典的 Bug 了。

请看下面的代码，大家觉得会打印什么？

import React, { useState, useEffect } from 'react';

function Timer() {
  const [seconds, setSeconds] = useState(0);

  useEffect(() => {
    const timer = setInterval(() => {
      console.log('当前秒数:', seconds); // 这里会打印什么？
    }, 1000);

    return () => clearInterval(timer);
  }, []); // 依赖数组是空的
}

export default Timer;

直觉告诉我们： 每秒都应该打印 0，然后变成 1，然后变成 2……

现实情况： 它只会打印 0。然后当你点击按钮更新状态（触发重新渲染）时，它依然打印 0。

为什么会这样？这就是闭包和堆栈分配共同作用的结果。

让我们像 React 一样，一步步拆解这个过程。

第一次渲染：

React 调用 Timer() 函数。
useState(0) 返回 [0, setSeconds]。此时，seconds 指向堆上的一个 0。
React 执行 useEffect 的回调函数。
- 注意！此时，useEffect 的回调函数是一个新的闭包。
- 这个闭包被创建在内存里（通常在堆上，或者作为闭包环境被引用）。
- 这个闭包里捕获了什么？它捕获了 seconds 的值（也就是 0），以及 setSeconds 的引用。
setInterval 启动，它保存了对这个闭包的引用。
函数 Timer() 执行完毕，局部变量（包括 seconds）被销毁（堆栈清空）。

第二次渲染（当你更新状态时）：

React 再次调用 Timer() 函数。
useState(0) 被重新执行，返回 [0, setSeconds]。注意，这里又是一个新的 0。
React 再次执行 useEffect 的回调函数。
- 关键点来了： React 会再次创建一个新的闭包！
- 这个新闭包里捕获的 seconds，是当前最新的值，也就是 0（虽然逻辑上我们希望它是 1，但在这个闭包创建的那一刻，它还是 0）。
setInterval 依然在运行，但它指向的是第一次渲染时创建的那个旧的闭包。那个旧闭包里保存的 seconds 还是 0。

结果： 无论你点击多少次，定时器里的 seconds 始终是第一次渲染时的那个快照。

这就是引用透明性带来的副作用： 当我们为了保持纯净，每次渲染都重新执行函数，重新创建局部变量时，我们同时也重新创建了闭包。如果 useEffect 依赖数组为空，它就会一直使用“旧”的闭包，导致逻辑失效。

第五幕：如何破解？useEffect 的依赖数组

既然知道了原理，怎么解决？

答案是：告诉 React，你的闭包里用到了什么，让它更新你的闭包。

我们修改 useEffect 的依赖数组：

useEffect(() => {
  const timer = setInterval(() => {
    console.log('当前秒数:', seconds); 
  }, 1000);

  return () => clearInterval(timer);
}, [seconds]); // 把 seconds 放进依赖数组

原理是这样的：

当 seconds 变化时，React 会检测到依赖数组变了。
React 会先清除（clearInterval）之前的定时器。
React 重新执行 useEffect 的回调函数。
创建一个新的闭包，这个新闭包里捕获的是最新的 seconds。
启动新的定时器。

这就叫“响应式更新”。通过暴露依赖，我们打破了堆栈分配带来的“快照效应”。

第六幕：性能优化——堆栈分配的代价

虽然堆栈分配非常快，不需要像堆那样进行复杂的垃圾回收，但是，如果我们在渲染过程中做了大量的计算，依然会拖慢速度。

假设我们在组件里写了一个很复杂的计算：

function ExpensiveComponent() {
  const [data, setData] = useState([]);

  // 每次渲染都重新计算这个大数组
  const bigData = [];
  for (let i = 0; i < 1000000; i++) {
    bigData.push({ id: i, value: Math.random() });
  }

  return <div>{data.length}</div>;
}

每次渲染，ExpensiveComponent 函数都会被调用。

函数进入，bigData 在堆栈上被创建（分配内存）。
100万次循环执行（CPU 消耗）。
bigData 生成完毕。
函数返回 JSX。
函数退出，bigData 被销毁（释放内存）。

虽然内存释放很快，但如果这个计算很重，你的页面就会卡顿。这就是所谓的“渲染期间的计算”。

逃逸分析

聪明的 JavaScript 引擎（比如 V8）其实能做点优化，叫逃逸分析。

如果引擎发现你创建的这个 bigData 对象，只是在这个函数里用了一下，然后就没了，它可能会把这个对象直接分配在堆栈上（而不是堆上），这样就能省去堆分配的开销。

但是！React 的特殊性在于，它需要把组件渲染的结果（JSX 对象）传给渲染器。这个结果通常需要逃逸到组件外部，所以引擎不能太激进地把所有东西都留在栈上。

解决方案：useMemo

为了不让 React 每次都重新计算，我们需要把计算结果“存”下来。但是，我们不能把它存在函数的局部变量里，因为函数每次都会重置。

我们要把它存在状态里，或者用 useMemo。

function ExpensiveComponent() {
  const [data, setData] = useState([]);

  // useMemo 告诉 React：只有当 data 变化时，才重新计算 bigData
  const bigData = useMemo(() => {
    const result = [];
    for (let i = 0; i < 1000000; i++) {
      result.push({ id: i, value: Math.random() });
    }
    return result;
  }, [data]); // 依赖 data

  return <div>{data.length}</div>;
}

这里发生了什么？

第一次渲染，data 是空，bigData 被计算并缓存。
第二次渲染，data 变了。React 检测到依赖变了。
React 不会重新执行函数体。
React 直接把缓存的 bigData 拿出来用。

这就避免了每次渲染都重新分配堆栈空间和重新计算的问题。

第七幕：深入探讨——Fiber 架构与堆栈

既然我们提到了 Fiber，咱们就聊聊 React 是怎么管理这些“堆栈分配”的。

React 16 之前，渲染是同步的，一调用函数就跑到底，如果函数里有死循环，浏览器就会假死。

React Fiber 引入了一个“可中断的渲染”概念。

这就像你在切菜。

传统的渲染是：拿起刀，切完所有菜，放下刀。如果菜太多了，你会切得手酸，且无法暂停。
Fiber 渲染是：拿起刀，切两下，放下刀，去检查一下有没有人喊你。切两下，放下刀，再检查。

在这个过程中，堆栈分配的作用更加微妙。

每次 Fiber 节点（对应一个组件）被调度执行时，它都会创建一个新的执行上下文。在这个上下文中，组件函数被调用，局部变量被分配。

如果渲染被中断了（比如用户点击了别的地方），这个堆栈上下文会被丢弃。等到 React 再次决定渲染这个组件时，它又会从头开始，重新分配堆栈。

这就是为什么我们在 useEffect 里不能依赖函数体内的局部变量，因为当 useEffect 回调真正执行时，渲染可能早就结束了，那些堆栈上的变量早就灰飞烟灭了。

第八幕：实战演练——一个完整的“Bug”教学片

为了巩固今天的知识，我们来做一个实战演练。

场景： 一个购物车，点击“结算”按钮，如果金额大于 100，就显示“恭喜中奖”。

错误的代码（闭包陷阱）：

import React, { useState } from 'react';

function Lottery() {
  const [money, setMoney] = useState(50);
  const [isWon, setIsWon] = useState(false);

  const handleCheckout = () => {
    setMoney(money + 50); // 假设我们加了50
    setIsWon(true);
  };

  // 错误的依赖
  useEffect(() => {
    if (isWon) {
      console.log('恭喜！你中了大奖！');
    }
  }, []);

  return (
    <div>
      <p>当前金额: {money}</p>
      <button onClick={handleCheckout}>支付 50 元</button>
    </div>
  );
}

运行逻辑分析：

初始状态： money 是 50，isWon 是 false。useEffect 回调执行，条件不满足。
点击按钮：
- handleCheckout 执行。
- setMoney(50) -> 触发重新渲染。
- setIsWon(true) -> 触发重新渲染。
第二次渲染：
- React 再次调用 Lottery 函数。
- useEffect 再次执行。注意！ 这里创建了一个新的闭包。
- 这个新闭包里的 isWon 是 true（因为这是当前渲染时的值）。
- 所以控制台打印了“恭喜！”。
- 等等，这看起来是对的啊？ 很多时候你会觉得这没问题。

让我们加个复杂的逻辑：

const handleCheckout = () => {
  const newMoney = money + 50;
  setMoney(newMoney);
  // 假设这里有个异步操作，或者我们想基于当前的计算结果来决定是否中奖
  if (newMoney > 100) {
    setIsWon(true);
  }
};

如果 newMoney 是 100，没中奖。isWon 还是 false。

渲染 1： isWon 是 false。
渲染 2： isWon 是 false。
渲染 3： isWon 是 false。

你看，虽然每次渲染时闭包里的 isWon 都是当前最新的 true 或 false，但是 useEffect 的副作用逻辑通常需要依赖状态的变化来触发。

如果我们把依赖数组写成空 []，React 就会认为“这个副作用不需要关心状态变化”。一旦渲染完成，useEffect 的回调就会“过期”，它不再监听后续的状态更新。

正确的写法：

useEffect(() => {
  if (isWon) {
    console.log('恭喜！你中了大奖！');
  }
}, [isWon]); // 依赖 isWon

这样，每次 isWon 变化（从 false 到 true），React 都会重新创建闭包，并执行副作用。

第九幕：总结——做一个聪明的 React 开发者

好了，同学们，今天的讲座接近尾声。让我们回顾一下今天学到的核心知识点，把它们串成一条线：

React 组件是函数： 它们遵循引用透明性，输出只取决于输入。
渲染即执行： React 会在需要的时候反复调用你的函数组件。
局部变量在堆栈： 每次 App 重新渲染，函数内的 let、const 都会被重新分配、重新赋值。它们是瞬态的，不会自动保留上一次的值。
闭包陷阱： useEffect 捕捉的是渲染那一刻的闭包环境。如果你不把变量放入依赖数组，React 就会一直用“旧”的闭包，导致逻辑失效。
性能优化： 避免在渲染过程中做昂贵的堆栈计算，使用 useMemo 来缓存计算结果。

最后，送给大家一句话：

不要试图在 React 的函数组件里寻找“持久化”的局部变量。如果你需要持久化，请去 useState 那里；如果你需要计算缓存，请去 useMemo 那里；如果你需要副作用，请老老实实写好依赖数组。

堆栈分配是为了快，为了干净，为了每一次渲染都是一张白纸，重新描绘最美的 UI。理解了这一点，你就理解了 React 的灵魂。

今天的课就上到这里，下课！希望大家以后写代码再也不被闭包坑，发际线永远坚挺！