React useEffect 副作用对象的环形链表存储模型：探究副作用在 Mutation 与 Layout 相位的物理调用时序机制
各位前端大佬，各位未来的架构师，大家下午好。我是你们的“副作用”观察员。
今天我们不聊业务逻辑，也不聊怎么把那个丑陋的 Modal 换成 Ant Design 的最新版，我们来聊聊 React 内部最隐秘、最底层，也是最折磨人的东西——副作用。
你肯定用过 useEffect。你肯定觉得它很简单：useEffect(() => {}, [])，就像你的人生规划一样，空空如也，或者填满了依赖项。但是，你以为 React 内部是怎么处理这些副作用的？你以为它们是像发快递一样，在组件渲染完的一瞬间“嗖”地一下就发走了吗？
错了。大错特错。
React 内部其实是在搞一个复杂的调度。今天，我们就要把 React 的这一块“黑盒子”给砸开，看看里面是不是藏着一只环形链表怪兽。我们要深入到 Fiber 节点，看看那些所谓的 Mount（挂载）、Update（更新）、Unmount（卸载）的副作用对象，是如何在 Mutation（变异）和 Layout（布局）这两个地狱般的相位之间，上演一场惊心动魄的物理时序大戏。
准备好了吗？我们要开始“解剖”了。
一、 不仅仅是回调函数：副作用对象的“前世今生”
首先，我们要建立一个概念：在 React 眼里，你的 useEffect 不是一个简单的函数，它是一个对象。
没错，就是一个对象。它有一个身份证号码（tag），有一个名字（callback），还有一个去处（deps）。这个对象在 React 内部被称为 Effect。
当你在组件里写下：
useEffect(() => {
console.log('我在执行');
}, []);React 会创建一个 Effect 对象，并且给它贴上标签：PassiveMount（被动挂载）。
这东西生下来是没地儿去的。它需要一个容器，一个能把它从“列表”里取出来并执行的容器。这个容器，就是环形链表。
你可能听说过 React 的 Fiber 树，那是数据结构；那这个环形链表呢？这是调度队列。
二、 环形链表模型：蛇，就是蛇
想象一下，你的组件树是一棵树，但在 React 渲染阶段，这棵树被拆解成了一个一个的节点（Fiber）。每个 Fiber 节点都有一个 firstEffect 和 lastEffect。
这就是环形链表的物理基础。
当一个 Fiber 节点有了副作用，React 就会把这个副作用对象挂在它身上。如果它是第一个，就挂在 firstEffect；如果是最后一个，就挂在 lastEffect。而为了形成“环”，React 会很魔幻地执行这一行代码：
// React 源码逻辑示意
if (fiber.lastEffect !== null) {
fiber.lastEffect.nextEffect = fiber.firstEffect;
}等等，这是什么操作？
这就像是把一条蛇的尾巴咬住了蛇头。你从一个节点开始，顺着 nextEffect 走，你会发现，你绕了一圈，又回到了起点。这就是“环形链表”的含义。
为什么这么做？为了方便。React 不想维护两个数组（一个数组存挂载，一个数组存更新），它只想维护一个队列。当你渲染完整个组件树，你只需要找到根节点的 firstEffect，然后顺着这条蛇，一路溜达过去，所有该干的活儿就都找到了。
副作用对象的“职业分工”：
在这个环形链表里，每个对象不仅仅是 useEffect。它们有不同的 tag：
- Mount（挂载）： 组件刚生下来，我们需要注册事件、请求数据。
- Update（更新）： 组件长大了，可能需要撤销上一次的效果。
- Unmount（卸载）： 组件挂了，我们需要清理现场，防止内存泄漏。
这些对象，就像是一群等待上台表演的演员。他们现在被关在 Fiber 节点的后台（渲染阶段），还在候场。这时候，你听到舞台那边传来了轰隆隆的声音，那是 DOM 在被修改。这就是我们接下来要讲的 Mutation 和 Layout 阶段。
三、 物理时序：渲染与提交的隔世断魂
这是 React 最核心的魔法所在。渲染阶段和提交阶段是两条平行线。
在渲染阶段，React 不会触动 DOM。它只是在你的脑海里构建了新的 Fiber 树，把那些 Effect 对象挂在树上。这个阶段是同步的，是残酷的，是为了算出“我要变什么”。
而提交阶段，才是真正的“物理时序”。DOM 就在这里出生，Mutation 和 Layout 阶段在这里发生，最后，我们的 useEffect 在这个链条的末端，优雅登场。
我们要搞清楚这个时间轴：
- Render（渲染）： React 跑完你的组件，收集好所有的 Effect 对象，把它们链成一个环。
- Commit（提交）： React 拿着这个环，开始干活。
四、 揭秘：Mutation 与 Layout 阶段（同步的狂欢）
在 React 18 的源码里，commit 阶段被切分成了三个小节：CommitBeforeMutationEffects（变异前）、CommitMutationEffects（变异）、CommitLayoutEffects（布局）。
我们重点看后面两个。
1. Mutation 阶段：DOM 的暴力美学
在这个阶段，React 开始真正地修改 DOM。它拿着新生成的 DOM 节点，替换旧的。
这是同步的。它会阻塞渲染主线程。React 必须要在这一刻把 DOM 变成你想要的样子。
你可能会问：“我的 useEffect 在哪里？”
useEffect 不在这里！useEffect 在后面的 Passive 阶段。所以，在 Mutation 阶段，你的 useEffect 回调函数还睡在环形链表里呢。它甚至不知道外面的世界已经天翻地覆了。DOM 已经被重绘了，类名已经被移除了，style 已经被加上了。
如果你在 useEffect 里去读取 DOM，你读到的可能是旧 DOM，也可能是新 DOM，视具体的浏览器实现和时序而定。这就是为什么 useEffect 里不能直接修改 DOM，因为你这时候根本没有拿到 DOM 呀！你只是在玩自己的逻辑，而 React 在旁边默默地把 HTML 给重写了。
2. Layout 阶段：布局的最后一口气
DOM 变更完了，React 进入 Layout 阶段。这个阶段通常用于执行 useLayoutEffect。
还记得我们说过的 useLayoutEffect 吗？它是 useEffect 的表亲，但它是同步的。它紧随在 Mutation 之后，在浏览器把屏幕绘制出来之前执行。
为什么？因为要算布局！当你修改了 width 或 height，浏览器的 Reflow（重排）是昂贵的。React 把这个重排计算放在这里，然后同步运行你的 useLayoutEffect。你可以在里面用 ref.current.getBoundingClientRect() 去拿最新的尺寸。
注意这里的关键点：
Layout 阶段是同步阻塞的。如果这里代码跑得慢，用户就会觉得页面卡顿了一下。React 知道这个危险，所以它把最耗时的异步操作——也就是我们的 useEffect，扔到了最后。
五、 终章：Passive 阶段与 useEffect 的降临
终于，我们到了故事的最末尾。Layout 阶段结束，浏览器拿到了最新的 DOM 状态，准备把那一帧画面画到屏幕上。
就在浏览器准备挥动画笔的前一秒，React 抓住了它。React 说：“兄弟，等一下。我还有一堆副作用没跑呢。”
这就是 Passive Effects（被动副作用） 阶段。
在这里，React 拿出了我们之前提到的那个环形链表。
// React 源码逻辑示意：Passive Effects 执行
let nextEffect = firstEffect;
while (nextEffect !== null) {
// 获取 tag，决定是 mount 还是 update
const effect = nextEffect;
nextEffect = nextEffect.nextEffect;
switch (effect.tag) {
case PassiveMount:
// 执行 useEffect 的回调函数
effect.create.callback();
break;
case PassiveUnmount:
// 清理之前的 useEffect
effect.destroy();
break;
}
}看，这就是 useEffect 的物理时序。它在 Mutation（改 DOM）之后，在 Layout（算布局）之前，最后在 Passive（跑回调）的时候被调用。
它是异步的。这意味着，你的 useEffect 回调函数执行时，浏览器已经完成了所有的 DOM 更新和布局计算。你可以在里面安全地操作 DOM，不用担心读不到最新的值，也不用担心阻塞渲染。
六、 代码示例：亲手构建一个环形链表
为了让大家彻底明白，咱们来写一段模拟代码。不依赖 React，我们自己造个轮子，模拟这个环形链表是如何存储和调用的。
// 定义副作用对象
class Effect {
constructor(tag, callback) {
this.tag = tag; // 0: PassiveMount, 1: PassiveUnmount
this.callback = callback;
this.nextEffect = null; // 链表指针
}
}
// 模拟 Fiber 节点（容器）
class FiberNode {
constructor() {
this.firstEffect = null; // 链表头
this.lastEffect = null; // 链表尾
}
// 添加副作用到环形链表
appendEffect(effect) {
if (this.firstEffect === null) {
// 第一次添加，形成闭环
this.firstEffect = effect;
this.lastEffect = effect;
effect.nextEffect = effect; // 自己指自己
} else {
// 追加节点
this.lastEffect.nextEffect = effect;
this.lastEffect = effect;
// 确保形成环
effect.nextEffect = this.firstEffect;
}
}
// 执行所有副作用（模拟提交阶段）
commitPassiveEffects() {
console.log('--- 开始执行 Passive Effects (useEffect) ---');
let currentEffect = this.firstEffect;
do {
if (currentEffect.tag === 0) { // PassiveMount
console.log(`[Mutation & Layout 之后] 执行挂载副作用:`, currentEffect.callback.toString());
currentEffect.callback(); // 这里就是 useEffect 的执行时刻！
}
// 简单的遍历逻辑
currentEffect = currentEffect.nextEffect;
} while (currentEffect !== this.firstEffect);
console.log('--- Passive Effects 执行完毕 ---');
}
}
// 模拟组件渲染过程
const rootFiber = new FiberNode();
// 1. 用户在组件里写了一个 useEffect
const myEffect = new Effect(0, () => {
console.log('我是 useEffect，我在 DOM 变更后、布局计算后运行！');
});
// 2. React 在渲染结束时，将这个 Effect 对象挂载到 Fiber 树上
rootFiber.appendEffect(myEffect);
// 3. 开始提交阶段
// (1) Mutation 阶段：React 改了 DOM
console.log('--- Mutation 阶段：DOM 被暴力重写 ---');
// (2) Layout 阶段：React 计算了布局
console.log('--- Layout 阶段：计算布局，执行 useLayoutEffect ---');
// (3) Passive 阶段：React 运行 useEffect
rootFiber.commitPassiveEffects();运行这段代码，你会发现输出顺序是：
- Mutation 阶段开始。
- Layout 阶段结束。
- Passive 阶段开始：
我是 useEffect...
这就是物理时序。useEffect 之所以能“透视” DOM 的变化，是因为它的运行时机恰恰是 DOM 变化完成之后。
七、 并发模式下的环形链表：地狱难度
现在，如果你只懂 React 16，那你只能算是入门。React 18 带来了并发模式。这时候，我们的环形链表模型就要面临考验了。
因为并发模式是“可中断”的。React 可能渲染了一半，被高优先级任务打断，去画一个 Modal，然后再回来继续渲染你的组件树。
这时候，环形链表可能会变得非常混乱。
想象一下，你在渲染组件 A 的 useEffect 时，被中断了。你刚把副作用挂到 A 的链表上。然后 React 切去画 B 组件了。B 组件渲染完，把自己的副作用也挂到了链表上。
当你回来继续渲染 A 时，你的链表结构可能会变成什么样？或者更糟糕，React 可能会在中途直接清空了 firstEffect，导致你的 useEffect 丢失？
React 的处理非常精细。
在并发模式下，useEffect 的执行被限制在“退出渲染”的瞬间。React 会在提交阶段重新遍历整个 Fiber 树，重新构建链表（或者根据差异进行更新），确保即使被中断了，最终提交的时候，所有的副作用都能被正确地推入 Passive 队列。
所以，虽然并发模式让时序变得极其复杂，但 React 依然保证了 useEffect 的语义：它总是在 DOM 变更之后，浏览器绘制之前运行。不管中间被打断了多少次。
八、 深度解析：为什么要分 Mutation、Layout 和 Passive？
这就涉及到 React 的设计哲学了。
为什么 useLayoutEffect 要在 Mutation 和 Layout 之间？
因为它同步。它是为了修正那些 DOM 操作带来的副作用。比如，你在 useLayoutEffect 里改变窗口的滚动条位置，这是同步的，用户不会感觉到跳动。
为什么 useEffect 要在最后？
因为它异步。它不应该阻塞浏览器渲染。如果 useEffect 里有一个 1 秒钟的计算，用户的界面就会卡死 1 秒钟。React 把它放在最后，是为了保证 UI 的响应速度。只有当画面都画好了，用户也看清了变化，再慢慢执行你的回调，这样体验最好。
环形链表的优势：
为什么要用链表而不是数组？
- 插入效率高： 在渲染阶段（同步，高频调用），往链表尾部插入一个对象（
appendEffect）是 O(1) 操作，不需要像数组那样移动后面的所有元素。 - 批量处理： React 可以一次性遍历这个环，把所有的
useEffect调度好，而不是触发一次就跑一次。
九、 避坑指南：环形链表里的陷阱
在实际开发中，虽然我们看不到环形链表，但副作用对象的执行顺序往往让人抓狂。
1. 同级组件的执行顺序
如果你有两个同级组件，都用了 useEffect，谁先跑？
这取决于它们在 Fiber 树中的父子关系，以及是挂载还是更新。
如果是挂载，子组件的 useEffect 会先于父组件的 useEffect 执行。因为子组件先渲染完，先挂载到链表上。
2. 依赖项的玄学
如果你的 useEffect 依赖项数组里包含了一个对象或函数，那你在环形链表里创建的 Effect 对象引用可能每次都不一样。
这会导致 React 认为“哎呀，这次要重新挂载这个 Effect”，从而触发卸载旧的，再挂载新的。这可能会打断你正在进行的网络请求（如果请求逻辑写在 useEffect 里），或者在动画中间突然重置状态。
3. 内存泄漏的元凶
记得我们说的环形链表吗？如果你的 Effect 对象里保存了对组件内部状态的引用，而这些状态在组件卸载时没有被清理，那么即使组件树变了，那个旧的状态依然“挂在”某个 Fiber 节点的链表上，等着被 useEffect 执行。这就是典型的内存泄漏。useEffect 返回的清理函数，就是为了在 PassiveUnmount 阶段把那个对象从链表里彻底剪断。
十、 总结：时序的艺术
我们今天通过层层剥茧，探究了 React useEffect 的内部机制。
我们没有看到什么花哨的魔法，只看到了最朴素的数据结构：环形链表。
React 通过在渲染阶段将副作用对象串联成链，在提交阶段的 Passive 阶段逐个执行，巧妙地隔离了异步副作用与同步 DOM 操作。
Mutation 阶段是暴力的 DOM 改造者，Layout 阶段是精算的布局调整师，而 useEffect（Passive 阶段）则是那个事后的整理者。
理解这个模型，能让你在写代码时更加得心应手。当你遇到 useEffect 执行顺序不对，或者性能问题时，你可以透过这些概念，想象出那个 Fiber 节点背后的环形链表正在疯狂地摆动，思考到底是哪一环卡住了。
希望这篇文章能让你对 React 的理解从“会写”上升到“精通”。毕竟，只有懂了底层原理，我们才能在技术面试的战场上，从容地用最简单的代码，说出最复杂的逻辑。
现在，关闭这个页面，去你的项目中找找看，那个隐藏在环形链表里的 useEffect，是不是正等着你去驾驭呢？