大家好，欢迎来到今天的 React 源码私享课。我是你们的老朋友，那个经常因为闭包陷阱而深夜痛哭、又因为 React 的奇妙设计而突然顿悟的编程专家。
今天，我们不聊那些花里胡哨的 Hooks 语法糖，也不聊那些让你头秃的并发模式。今天，我们要钻进 React 的核心引擎房，去拆解一个听起来平淡无奇、实则掌控着组件生死的函数——pushEffect。
我们要聊什么？内存分布。
在 React 的世界里，内存不是免费赠品，尤其是当你组件里挂了一堆 useEffect 的时候。你有没有想过，当你写了十个 useEffect，React 怎么知道哪个先跑，哪个后跑，以及当你卸载组件时，React 怎么知道要清理哪些脏活累活？这一切，都归功于这个 pushEffect 函数在内存里的一番精妙布局。
准备好了吗？把你的 IDE 打开，把你的咖啡倒满。我们开始这场深潜。
一、 背包系统：memoizedState 的奇妙漂流
在深入 pushEffect 之前，我们必须先理解 React Fiber 的一个核心概念：memoizedState。
你可以把每个 React 组件实例想象成一个正在搬家的工人（Fiber 节点）。这个工人有两个背包：一个叫 memoizedState，一个叫 updateQueue。updateQueue 是给 useState 用的，用来存你要改变的数据；而 memoizedState，则是给 Hooks 用的，用来存所有的“副作用”。
为什么叫 memoizedState？ 因为它就是组件当前的状态快照，不仅仅是数据，还包括所有的 Hook 链表。
当你的组件第一次渲染时，memoizedState 通常是 null。这时候，React 会执行 useState，给这个 null 赋值一个初始状态。
但是，当你写下了 useEffect(() => {}, [])，神奇的事情发生了。
React 并不是在内存里开了一个新的数组把 useEffect 扔进去，而是像链表一样，挂载在 memoizedState 的末尾。这就是 React 高效处理 Hooks 的秘密武器：链式结构。
所以，当我们谈论 pushEffect 时，我们实际上是在谈论：“如何在当前的 memoizedState 链表末尾，塞入一个新的节点，并处理好内存指针的指向？”
二、 pushEffect 的庐山真面目
现在，让我们把目光投向源码。在 packages/react-reconciler/src/FiberHooks.js 文件中，你找到了这个函数。
别被它的签名吓到了。它接收了一堆参数，但归根结底，它只做三件事：创建对象、分配内存、挂载链表。
我们先看一个简化版的伪代码，看懂了它，内存分布就懂了一半：
function pushEffect(tag, payload, create, destroy) {
// 1. 创建一个 effect 对象
// 这个对象是我们在堆内存中分配的一块领地
const effect = {
tag, // 标记：这是 Layout 还是 Passive？
create, // 生命周期：创建副作用
destroy, // 生命周期：销毁副作用
deps, // 依赖数组
next: null // 链表指针：下一个人（下一个 Hook）在哪里？
};
// 2. 处理链表挂载
// 注意看，这里的逻辑有点绕，我们需要先找到链表的尾巴
// 让我们看看 React 是怎么做的（源码细节）
let lastEffect = fiber.memoizedState;
if (lastEffect === null) {
// 情况 A：这是第一个 Hook
// memoizedState 直接指向这个 effect，形成闭环
fiber.memoizedState = {
baseState: null,
baseQueue: null,
queue: null,
next: effect
};
} else {
// 情况 B：链表已存在，我们只是来串门的
// 我们要把 effect 接在 lastEffect.next 上
// 并且把 lastEffect.next 指向 effect，形成新闭环
lastEffect.next = effect;
}
// 3. 返回必要的值
// 这里有个骚操作，如果是 LayoutEffect，它会返回 destroy 函数
// 如果是 PassiveEffect，它返回 null
// 这个返回值决定了 React 后续怎么调度
if (destroy !== undefined) {
return destroy;
}
}看到没？这就是内存分布的核心逻辑。我们不是在平铺直叙，我们是在编织。
三、 内存布局的拓扑结构
让我们深入剖析这个链表结构。想象一下，你的组件里有三个 Hook：
useState(初始值: 10)useEffect(回调: A)useEffect(回调: B)
在内存中，fiber.memoizedState 首先指向的是 useState 对象，而这个对象里包含了一个 next 属性，指向了 useEffect 的对象。
这就形成了一条长龙：
[memoizedState] --|
(useState obj) |
(next: ptr) |
(val: 10) |
|---> [useEffect A obj]
| (next: ptr)
| (create: fn_A)
| (destroy: fn_A_destroy)
|
|---> [useEffect B obj]
| (next: ptr)
| (create: fn_B)
| (destroy: fn_B_destroy)
|
V
null这个内存结构有什么用？
当 React 需要执行副作用时，它不需要知道你的组件写了多少个 useEffect。它只需要拿着 memoizedState 这个头节点，一路 next 下去，遇到谁就执行谁的 create，遇到谁就注册谁到调度器。
这就是为什么 React 必须强制要求 Hook 写在函数体顶部的原因。如果有人把 useEffect 写在 if 判断里面，或者写在一个条件分支里，那么链表就会断裂。因为 pushEffect 是按顺序执行的，如果跳过了，后面的内存指针就会指向 undefined，导致运行时崩溃。
四、 Tag：效果的生命周期与内存分类
pushEffect 函数的第一个参数是 tag。这个参数简直就是 React 的“二进制分类器”。它决定了这段内存数据在渲染周期的哪个时间点被激活。
我们可以从源码里看到 EffectTag 的定义：
const LayoutEffectTag = 0x1; // 1
const PassiveEffectTag = 0x2; // 2
const InsertionEffectTag = 0x3; // 3 (少用，CSS-in-JS 相关)
const DeletionTag = 0x4; // 4 (卸载)这些数字不仅仅是标签，它们直接决定了 React 调度器如何处理这些对象。这不仅是内存分布的问题，更是时间分布的问题。
1. LayoutEffect (tag = 1): 严阵以待
当 pushEffect 收到 LayoutEffectTag 时，意味着你使用了 useLayoutEffect。
这些副作用必须在浏览器绘制屏幕之前执行。
在内存处理上，React 会把这些 Effect 放入一个 layoutEffects 队列中。
在 commit 阶段（渲染提交阶段），React 会同步遍历这个队列。
内存分配策略： 此时，memoizedState 链表上的这些对象是活的，它们等待着被调用。
2. PassiveEffect (tag = 2): 逍遥法外
当 pushEffect 收到 PassiveEffectTag 时，这意味着你使用了 useEffect。
这些副作用可以安全地“睡觉”，等浏览器忙完绘制，交给事件循环再去执行。
React 会在 commit 阶段结束后，把所有带有 PassiveEffectTag 的 effect 对象收集起来，推入 scheduleCallback，触发浏览器的空闲回调。
内存分配策略： 这段内存虽然分配了，但它暂时挂起。只有当调度器真正触发空闲时间，才会去执行 effect.create。
3. InsertionEffect (tag = 3): 懒惰的中场
这个比较冷门，用于 useInsertionEffect。它在 CSS-in-JS 库（比如 emotion, styled-components）里很有用。它执行在 DOM 更新之前，但在 LayoutEffect 之前。
内存分布： 它和 PassiveEffect 一样，也是一种懒加载策略。
为什么这种分类对内存重要？
因为它控制了对象的生命周期。
- 如果你在
useEffect里保存了巨大的 DOM 节点引用，而 React 正好在这个时候 GC（垃圾回收）了，那你的闭包引用就悬空了。React 的调度策略保证了PassiveEffect的执行不会阻塞主线程，从而给浏览器回收内存留出了机会。
五、 create 与 destroy：内存的二元对立
pushEffect 接收了两个关键函数：create 和 destroy。
useEffect(() => {
// create
const subscription = dataSource.subscribe();
return () => {
// destroy
subscription.unsubscribe();
};
}, []);在 pushEffect 的内存模型里，create 是一个承诺，destroy 是一个备份。
当你第一次执行 pushEffect 时，create 被存入对象的 create 属性。
关键点来了：destroy 什么时候进入内存？
答案是：在组件第二次渲染（更新）时。
当你调用 setState 触发组件重新渲染时，React 会再次遍历 memoizedState 链表。它会比较新旧 create 函数的依赖数组。
- 如果依赖没变，React 就不动了，保持旧的内存状态。
- 如果依赖变了，React 就会取出旧的
effect.destroy执行。
这里有一个非常精妙的内存逻辑：更新时，旧的 create 变成了 destroy 的参数；新的 create 被填入 create 属性。
这听起来可能有点绕，我们用代码来模拟一下内存的变化：
// 初始渲染
pushEffect( PassiveEffectTag, null, () => {
console.log("创建副作用 1");
return () => console.log("清理副作用 1");
}, undefined);
// 此时内存结构：
// [Effect1] { create: fn1, destroy: undefined, ... }// 第二次渲染，依赖变化
pushEffect( PassiveEffectTag, null, () => {
console.log("创建副作用 2 (因为依赖变了)");
return () => console.log("清理副作用 2");
}, undefined);
// 此时内存结构发生了剧烈变化：
// React 执行了 Effect1.destroy (打印了清理副作用 1)
// React 更新了 Effect1 的 create 属性为 fn2
// Effect1 的 destroy 属性被赋值为旧的那个 fn1 (虽然暂时用不到，但占着坑位)
// [Effect1] {
// create: fn2, // 新的任务
// destroy: fn1, // 旧的清理函数（为了配合 fn1 重新调用）
// ...
// }
// [Effect2] { create: fn2, destroy: undefined, ... }为什么要把旧的 create 赋值给新的 destroy？
因为如果依赖变了，就意味着我们不再需要旧的 create 了，所以它变成了 destroy。
而且，当函数重新执行时，这个函数（闭包）里引用的外部变量必须被更新到最新的状态。如果只更新 create 而不处理 destroy 的闭包，你的清理函数里可能还拿着旧的数据，导致错误的清理行为。
六、 深度剖析：pushEffect 在不同场景下的内存表现
为了真正理解 pushEffect，我们不能只看静态图，要看它在 React 处理逻辑时的动态表现。
场景一：组件卸载
这是内存回收最关键的时刻。
当 React 决定卸载组件时（比如路由跳转走了），它会执行一个卸载队列。
它拿着 fiber.memoizedState 这个头，一路遍历到链表末尾。
对于每一个 effect 对象：
- 如果是 LayoutEffect：执行
effect.create()。注意，这里没有destroy！LayoutEffect 在挂载时返回的 destroy 是同步执行的，不需要存起来。所以卸载时，LayoutEffect 只是简单的调用一次。 - 如果是 PassiveEffect：在
commit阶段收集时，React 会把effect.destroy也收集起来。在卸载阶段，遍历passiveUnmountEffects队列，调用所有保存下来的destroy函数。
内存释放：
这里有一个有趣的点。pushEffect 创建的 effect 对象通常包含对组件内变量（闭包）的引用。
在 JavaScript 中，当一个对象（比如 effect）不再被任何地方引用时，垃圾回收器（GC）就会把它清理掉。
当你调用 destroy 时，你通常是在断开外部资源的连接（比如取消订阅、清除定时器）。这不仅是释放内存的逻辑，更是防止内存泄漏的防线。 如果你不返回 destroy，React 就不知道要帮你清理，那个资源（比如 WebSocket 连接）就会一直挂在那儿，等待内存耗尽。
场景二：高阶组件与 Context
这涉及到 pushEffect 的一个特殊行为。
当你把一个组件包装在 useEffect 里，或者在高阶组件里使用时，内存的分布会变得稍微复杂一点点。
pushEffect 是挂载在当前 Fiber 节点上的。
这意味着，如果你在一个父组件的 useEffect 里创建了一个子组件的引用，那么这个子组件的 memoizedState（以及它所有的 effect）都会被父组件的 effect 引用链所持有。
这就是所谓的“内存泄漏”温床。只要父组件的 memoizedState 链表不断裂，子组件的 effect 对象就永远不会被垃圾回收。
七、 代码实战：手写一个迷你版 pushEffect
为了让你彻底摸清 pushEffect 的内存脉络，我们来写一个极其简化但包含核心逻辑的版本。请仔细阅读代码中的注释，那是通往内存世界的地图。
// 模拟 Fiber 节点
class FiberNode {
constructor() {
this.memoizedState = null; // 核心：Hook 链表的头
}
}
// 模拟 Effect 对象
function createEffectNode(tag, create, destroy) {
return {
tag, // 1 (Layout) 或 2 (Passive)
create, // 生成副作用的函数
destroy, // 清理副作用的函数
next: null, // 指向下一个 Effect
};
}
/**
* 核心函数：pushEffect
* @param {number} tag - 效果的标签
* @param {function} create - 创建副作用的函数
* @param {function} destroy - 销毁副作用的函数
*/
function pushEffect(fiber, tag, create, destroy) {
// 1. 构建节点
const effect = createEffectNode(tag, create, destroy);
// 2. 处理链表逻辑
// 如果 memoizedState 为空，说明这是这个组件挂载后的第一个 Hook
if (fiber.memoizedState === null) {
fiber.memoizedState = {
baseState: null,
baseQueue: null,
queue: null,
next: effect // 形成闭环：State -> Effect -> next -> State
};
console.log("内存布局: 新建链表，memoizedState 指向 Effect");
} else {
// 如果已有 Hook，说明我们要追加新的 Effect
// 此时 memoizedState 指向的是 "上一个" Hook 的 State 对象
// 我们需要拿到这个 State 对象的 next 属性，也就是当前链表的最后一个 Effect
let lastEffectNode = fiber.memoizedState.next;
// 遍历到最后一个
while (lastEffectNode.next !== null) {
lastEffectNode = lastEffectNode.next;
}
// 把新 Effect 接在后面
lastEffectNode.next = effect;
// 形成闭环：倒数第二个 Effect -> 新 Effect -> State -> ...
console.log("内存布局: 追加 Effect 到链表末尾");
}
// 3. 特殊处理：如果是 useLayoutEffect，需要返回 destroy
// React 源码中这里有一大堆判断逻辑，用于区分不同阶段的副作用
if (tag === 1) { // LayoutEffectTag
return destroy;
}
return null;
}
// --- 测试场景 ---
const fiber = new FiberNode();
// 1. 挂载 useEffect
console.log("执行 useEffect A");
// 这里的逻辑是：创建 Effect -> 挂载到链表 -> 返回 destroy -> 存入某个全局队列(这里简化)
pushEffect(fiber, 2, () => {
console.log(" -> Effect A 执行了 (Passive)");
return () => console.log(" <- Effect A 清理了");
}, undefined);
// 2. 挂载 useLayoutEffect
console.log("n执行 useLayoutEffect");
pushEffect(fiber, 1, () => {
console.log(" -> Effect B 执行了 (Layout)");
return () => console.log(" <- Effect B 清理了");
}, undefined);
// 3. 绘制内存拓扑结构
let current = fiber.memoizedState;
console.log("n--- 内存拓扑结构 ---");
while(current) {
const effectNode = current.next;
if (effectNode) {
console.log(`[Hook State] --(next)--> [Effect ${effectNode === fiber.memoizedState.next ? 'A' : 'B'}]`);
current = effectNode;
} else {
break;
}
}
八、 总结与深度思考
通过上面的分析和代码演示，我们可以清晰地看到 pushEffect 在内存分布上的几条铁律：
- 线性链表结构：它不使用哈希表，不使用数组。它使用链表。为什么？因为 Hooks 的执行顺序必须严格遵守声明顺序。链表是维护顺序最简单、内存开销最小的结构。
- 闭包陷阱的温床：
create和destroy函数捕获了当时的组件状态。pushEffect把这些函数存在了 Fiber 节点的内存中。只要组件不卸载，这些函数（以及它们引用的变量）就会一直赖在内存里不走。 - Tag 决定生命周期：
pushEffect创建的同一个对象实例，会因为tag的不同，经历不同的生命周期阶段（Layout vs Passive）。这在内存管理上意味着：有些对象在渲染期间就活跃了，有些对象则是“懒加载”的。 - 更新机制：更新不仅仅是替换数据，更是替换
create，同时把旧的create降级为destroy。这是一种非常精妙的内存复用和状态同步策略。
最后的思考：
当你下次写 useEffect 的时候，请记得 pushEffect 正在后台默默地在你的组件 Fiber 上挂载一根指针。当你写 return () => {} 的时候，你不仅仅是写了一个清理函数，你是在给 pushEffect 提供一把钥匙，用来在未来的某个时刻（组件卸载或更新时）打开这把锁，释放内存。
React 的内存管理，就是在这种精细的指针操作和生命周期调度中诞生的。它看似简单（链表+函数），实则复杂（闭包+调度+垃圾回收）。
希望这篇讲座能帮你把 pushEffect 这个函数从“黑盒”变成“白盒”。下次看到控制台报错说“超过最大更新次数”或者内存飙升时，别慌，想想那些链表指针，想想那些闭包函数，它们正在你的内存里开会呢！
好，今天的源码深潜就到这里。别忘了把 destroy 函数写对，这是对内存最大的尊重。我们下次见！