React 副作用列表的物理存储：源码解析从 firstEffect 到 lastEffect 的链表指针维护逻辑 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

好，各位同学，把手里的螺丝刀放一放，把代码编辑器打开，今天我们不开会，也不讲那些虚头巴脑的架构图。我们要钻进 React 源码的深处，去解剖一个极其精妙、又极其“链表”的数据结构。

这事儿说起来挺枯燥，但我保证，一旦你搞懂了它，你就不会再被 useEffect 的执行顺序搞晕了，甚至你会觉得这种指针操作比跳绳还带劲。

我们今天要聊的是：React 副作用列表的物理存储——从 firstEffect 到 lastEffect 的链表指针维护逻辑。

听名字有点长是吧？别急，我们把它拆开。想象一下，React 的每一个 Fiber 节点，不仅仅是一个普通的对象，它更像是一个穿着西装、打着领带、但口袋里塞满了各种票据的商务人士。这些“票据”就是副作用。而 React 为了高效地管理这些票据，在 Fiber 节点的属性里，埋了两条线：一条叫 firstEffect（第一条线），一条叫 lastEffect（最后一条线）。这两条线连起来，就是一个完整的副作用链表。

来，咱们直接上代码，直接上源码。

一、节点的诞生：`createEffectNode`

首先，你得有个节点。在 React 源码里，这个节点不仅仅是指向下一个节点的指针，它本身就是一个独立的个体。它长这样（简化版）：

// ReactFiberHooks.js 或 ReactFiberWorkLoop.js 中
function createEffectNode() {
  const effectNode = {
    baseTag: 0,       // 基础标签，比如是否是 layout effect
    nextEffect: null, // 指向下一个节点的指针，这是关键！
    firstEffect: null,// 指向这个节点包含的子 effect 链表
    lastEffect: null, // 指向这个节点包含的最后一个子 effect
  };
  return effectNode;
}

注意看这个结构。它不仅仅是一个指针，它还包含了自己的 nextEffect，以及指向自己子级链表的 firstEffect 和 lastEffect。

为什么这么设计？这就像是“容器与物品”的关系。 createEffectNode 创建了一个容器，这个容器可以容纳多个 Effect（通过 firstEffect 和 lastEffect），同时它自己也是一个 Effect（通过 nextEffect 连接父级）。

当 React 决定要创建一个 Effect 时，它会调用 createEffectNode。这个函数执行的时候，最关键的一步是初始化 nextEffect 和 lastEffect 指针。通常我们会把它们指向自己，形成一个环，或者指向 null。

function createEffectNode() {
  const effectNode = {
    baseTag: 0,
    nextEffect: effectNode, // 初始时，自己指向自己（形成环）
    firstEffect: null,
    lastEffect: null,
  };
  return effectNode;
}

专家点评： 这里的 nextEffect 指向自己，是一个典型的“哨兵”或者“环状链表”的初始化技巧。这在后续插入节点时非常有用，因为它意味着“如果我是最后一个，我就指向我自己，不需要额外判断 null”。

二、挂载的瞬间：`attachFiberEffect`

好了，节点生成了，现在得把它挂到 Fiber 树上。这就是 attachFiberEffect 函数要做的事。这个函数通常在组件初次渲染或者更新时被调用。

假设我们现在有一个 workInProgress（正在构建的工作 Fiber 节点），我们要把一个刚刚创建好的 effectNode 挂上去。

场景 1：这是该 Fiber 节点上的第一个副作用
如果这个 Fiber 节点原本没有副作用（firstEffect 是 null），那么这个新节点就是老大。firstEffect 和 lastEffect 都指向它。

function attachFiberEffect(fiber, effectNode) {
  // 如果该 fiber 没有任何副作用，那这个 effectNode 就是它的头和尾
  if (!fiber.firstEffect) {
    fiber.firstEffect = effectNode;
    fiber.lastEffect = effectNode;
  } else {
    // 场景 2：后面会讲，这里先别急
  }
}

场景 2：该 Fiber 节点已经有副作用了
如果 fiber.firstEffect 已经存在，说明这棵树上已经有“前人栽树”了。这时候，我们就要把新来的这个 effectNode 插到队伍的末尾。

这就是 lastEffect 的作用。lastEffect 保存着当前链表的最后一个节点。我们要做的，就是让“最后一个人”指认“新来的人”是老大（即 nextEffect = effectNode），然后让“新来的人”指认“最后一个人”是前一个（即 effectNode.prevEffect = lastEffect）。

function attachFiberEffect(fiber, effectNode) {
  if (!fiber.firstEffect) {
    fiber.firstEffect = effectNode;
    fiber.lastEffect = effectNode;
  } else {
    // 1. 找到当前链表的尾巴
    const lastFiberEffect = fiber.lastEffect;

    // 2. 老尾巴指向新节点
    lastFiberEffect.nextEffect = effectNode;

    // 3. 新节点指认老尾巴
    effectNode.prevEffect = lastFiberEffect;

    // 4. 更新 Fiber 节点的 lastEffect 指针
    fiber.lastEffect = effectNode;
  }
}

这里有个细节非常迷人： 你会发现代码里并没有直接操作 effectNode.nextEffect 指向 fiber.firstEffect。为什么？因为 fiber.firstEffect 是整棵树全局的起点，而 nextEffect 是节点间的连接。在这个挂载阶段，我们只需要维护好 fiber 节点自己的 firstEffect 和 lastEffect 指针，让它们指向链表的头和尾。至于链表内部怎么走，那是后面遍历的事。

三、更新的博弈：`processPendingEffects`

这是最精彩的部分。React 是怎么知道哪些 useEffect 需要重新执行的？哪些需要清理的？

当组件更新时，React 会比较新旧 Props 和 State。如果有变化，它会触发 Effect 的更新。这个过程在源码中通常涉及 processPendingEffects 函数。

这时候，React 会在 workInProgress 节点上维护一份“待处理”的 Effect 列表（通常存在 pendingEffects 或者通过 nextEffect 遍历得到）。我们的任务是把这份“旧”列表和“新”的 Effect 节点合并。

这里的核心逻辑是：遍历旧链表，判断依赖项是否变化，如果变化，就创建新的 Effect 节点并挂载。

function processPendingEffects(fiber) {
  // 假设 pendingEffects 是一个包含所有待处理 Effect 标志的对象
  // 这里为了演示，我们简化为遍历 fiber 上现有的链表结构

  let lastEffect = null;
  let nextEffect = fiber.firstEffect;

  while (nextEffect !== null) {
    // 1. 检查依赖项
    // 在源码里，这里会有复杂的逻辑去判断 effectNode.memoizedProps 
    // 和当前 fiber 的 props 是否匹配，或者依赖的 state 是否变了。

    // 假设这里判断出依赖没变，不需要执行，那我们跳过这个节点
    if (shouldNotRunEffect(nextEffect, fiber)) {
      // 跳过逻辑：将 nextEffect 移到下一个
      // 注意：这里不仅仅是跳过执行，还要从链表中移除
      nextEffect = nextEffect.nextEffect; 
      continue;
    }

    // 2. 依赖变了！我们需要创建一个新的 Effect 节点来标记这次更新
    // 比如：创建一个 layout effect 节点，或者 passive effect 节点
    const newEffectNode = createEffectNode();
    // 设置一些属性，比如回调函数、依赖项等
    newEffectNode.callback = nextEffect.callback; 
    newEffectNode.tag = nextEffect.tag; 

    // 3. 关键点：如何维护链表？
    // 我们要把这个 newEffectNode 插入到链表中。
    // React 的策略通常是：把新节点插入到旧节点之前（或者之后，取决于副作用类型）。
    // 为了演示方便，我们假设我们要把新节点插入到链表的头部，或者作为 lastEffect。

    if (!fiber.firstEffect) {
        fiber.firstEffect = newEffectNode;
        fiber.lastEffect = newEffectNode;
    } else {
        // 插入逻辑：新节点 -> 旧节点 -> ...
        const oldNextEffect = nextEffect; // 保存旧的 nextEffect

        // 指针操作
        newEffectNode.nextEffect = nextEffect;
        nextEffect.prevEffect = newEffectNode;

        // 更新 Fiber 节点的 firstEffect（如果是插在头）
        fiber.firstEffect = newEffectNode;
    }

    // 更新 lastEffect
    fiber.lastEffect = newEffectNode;

    // 更新循环指针
    nextEffect = newEffectNode.nextEffect;
  }
}

专家点评： 看到没？这就是物理存储的奥妙。React 并不是简单地删除旧的节点，而是通过指针的重新连接，动态地构建出新的链表结构。nextEffect 和 prevEffect 就像是两根看不见的橡皮筋，React 拉扯它们，就能瞬间改变副作用列表的形态。

四、执行的号角：`commitBeforeMutationEffects`

好了，链表建好了，节点都挂好了。现在到了最激动人心的时刻：提交阶段。

React 必须按照特定的顺序执行这些副作用。React 为什么要分 BeforeMutation（变异前）、Layout（布局）、Passive（被动）三个阶段？就是因为链表的指针维护逻辑不同。

在 commitBeforeMutationEffects 阶段，React 会开始遍历 firstEffect 链表。

function commitBeforeMutationEffects(root, committedFiber) {
  let nextEffect = root.firstEffect;

  while (nextEffect !== null) {
    // 1. 根据 tag 判断这是什么类型的副作用
    // 比如：LayoutMask, PassiveMask 等
    const tag = nextEffect.tag;

    // 2. 根据类型执行不同的回调
    if (tag === PassiveEffect) {
      // 执行 useEffect
      schedulePassiveEffects(nextEffect);
    } else if (tag === LayoutEffect) {
      // 执行 useLayoutEffect
      invokeGuardedCallback(nextEffect.callback);
    }

    // 3. 遍历下一个节点
    nextEffect = nextEffect.nextEffect;
  }
}

注意这里： 在遍历的过程中，nextEffect 这个指针扮演了“游标”的角色。它从 root.firstEffect 开始，一步步向后移动。一旦一个节点执行完毕，React 就会通过 nextEffect 找到下一个。

但是！如果你仔细看上面的代码，你会发现一个问题：如果我在回调函数里把 nextEffect 修改了怎么办？ 或者说，如果回调函数报错了怎么办？

React 的源码处理非常严谨。它会在执行回调之前，把当前的 nextEffect 保存到一个临时变量里，执行完之后再恢复。这保证了链表遍历不会因为业务逻辑而崩塌。

五、清理的魔法：`nextEffect` 作为“下一个”

这里我要强调一个经常被忽略的概念：nextEffect 的双重身份。

在链表维护阶段，nextEffect 是指向前一个节点的“前驱”指针（或者在某些实现中是双向链表）。
但在遍历执行阶段，nextEffect 被临时重用为“后继”指针。

当 React 完成对一个 Effect 节点的处理，它需要跳到下一个节点。它直接读取 nextEffect.nextEffect。这非常高效，不需要额外的变量来存储索引。

物理存储的终极奥义：
当 React 决定要“清理”一个 Effect 时，它实际上是在操作指针。

比如，一个 useEffect 的清理函数执行完了，React 就会把这个节点从链表中“摘”下来。怎么做？很简单，让前一个节点的 nextEffect 指向当前节点的 nextEffect，然后让当前节点的 nextEffect 指向 null。

function detachEffectNode(effectNode) {
  // 假设 effectNode 是链表中间的一个节点
  const prevEffect = effectNode.prevEffect;
  const nextEffect = effectNode.nextEffect;

  if (prevEffect) {
    prevEffect.nextEffect = nextEffect;
  }

  if (nextEffect) {
    nextEffect.prevEffect = prevEffect;
  }

  // 可选：断开当前节点的连接，防止内存泄漏或误用
  effectNode.prevEffect = null;
  effectNode.nextEffect = null;
}

在 React 的提交阶段，当 commitBeforeMutationEffects 循环结束时，整个链表其实已经被“遍历”了一遍。React 会遍历所有节点，执行回调，然后断开它们的连接。最终，fiber.firstEffect 和 fiber.lastEffect 都会变成 null。

专家点评： 这就是为什么 React 的副作用执行是单线程、顺序执行且严格受控的。因为它们本质上就是一个物理链表。你不能跳过中间的节点，也不能并行执行，因为链表的结构决定了你必须先到头，才能去尾。

六、父子关系的嵌套：`firstEffect` 与 `lastEffect` 的层级

最后，我们来聊聊最复杂的场景：父子组件的 Effect 链表。

React 的 Effect 执行顺序是：父组件的 Layout Effect -> 子组件的 Layout Effect -> 父组件的 Mutation -> 子组件的 Mutation -> 父组件的 Passive -> 子组件的 Passive。

这个顺序是怎么保证的？全靠 firstEffect 和 lastEffect 的嵌套维护。

想象一下，父组件有一个 useLayoutEffect，子组件也有一个 useLayoutEffect。

挂载时：
- React 先创建子组件的 Effect 节点，挂载到子 Fiber 的 firstEffect。
- 然后 React 创建父组件的 Effect 节点。
- 在挂载父组件的 Effect 节点时，React 会检查父 Fiber 的 firstEffect。发现没有，那就把父节点的 firstEffect 和 lastEffect 都指向父节点。
- 关键点来了： 父节点会把自己的 firstEffect 指向子节点吗？是的！在 attachFiberEffect 的逻辑里，如果父节点有副作用，它会把子节点的 Effect 链表挂到自己的 firstEffect 下面。
结构变成了这样：
```
Fiber (父)
  ├─ firstEffect --> 父节点
  │   ├─ nextEffect --> 子节点 (子 Fiber 的 firstEffect)
  │   │   └─ nextEffect --> ...
  └─ lastEffect --> 父节点
```
执行时：
React 从 root.firstEffect 开始遍历。
- 遇到父节点：执行父 Effect。
- 遇到父节点的 nextEffect：发现它指向了子节点的 firstEffect。
- React 进入子节点链表，执行子 Effect。
- 子节点执行完后，回到父节点。
这就是深度优先遍历。firstEffect 和 lastEffect 这种结构，天然支持这种嵌套的树形遍历。父节点的 firstEffect 指针指向它自己的 Effect，但也指向它子树的根节点。

七、总结与“吐槽”

好了，讲到这里，我们对 React 副作用列表的物理存储应该有了清晰的认识。

我们看到的不仅仅是几个变量：firstEffect，lastEffect，nextEffect。
我们看到的是一种动态的、指针驱动的内存管理艺术。

firstEffect 是头，是全局入口。
lastEffect 是尾，是快速插入的终点。
nextEffect 是桥梁，连接过去与未来，既是链表的元素，又是遍历的指针。

React 为什么要这么折腾？为什么不直接存一个数组？
因为数组插入是 O(N)，链表插入是 O(1)。 React 每一帧都在创建和销毁大量的 Effect 节点。如果你用数组，每次添加一个 Effect 都要移动后面所有的节点，那性能会直接崩盘。用链表，只要改改指针，瞬间搞定。

还有一个好处： 链表天然支持嵌套。React 的 Effect 执行顺序（父子、Layout/Passive）完全由链表的结构决定。你想改执行顺序？改指针的连接方式就行了。

但是！ 链表也有它的坑。指针多了，容易断。如果指针乱了，React 就会报错，甚至导致内存泄漏。这也是为什么 React 的源码里充满了 if (nextEffect === null) throw new Error(...) 这种防御性代码。

所以，下次当你写 useEffect 的时候，别忘了，你的代码背后有一根看不见的线，一根由 nextEffect 和 lastEffect 纠缠而成的线，正牵着 React 的执行引擎，在内存的海洋里飞速穿梭。

这就是 React 的物理存储，链表之美，在于指针的每一次跳动。

好了，今天的讲座就到这里。大家下去把源码里的 ReactFiberHooks.js 和 ReactFiberWorkLoop.js 打开，看看 attachFiberEffect 和 commitBeforeMutationEffects 的实现，你会发现，代码里的注释都在对你点头微笑。

下课！

一、 节点的诞生：createEffectNode

二、 挂载的瞬间：attachFiberEffect

三、 更新的博弈：processPendingEffects

四、 执行的号角：commitBeforeMutationEffects

五、 清理的魔法：nextEffect 作为“下一个”

六、 父子关系的嵌套：firstEffect 与 lastEffect 的层级

七、 总结与“吐槽”

发表回复 取消回复