各位好！欢迎来到 React 源码的“后花园”。我是你们的老朋友，今天我们要聊的不是那些花里胡哨的 Hooks 封装，也不是那些能让你在面试中吹牛的高级模式，而是 React 内部最基础、最底层的“齿轮”——useEffect 的执行机制。
很多人以为 useEffect 就是一个简单的 setTimeout，或者是把函数扔进队列里等着执行。大错特错！如果 React 只是这么简单，那它处理不了并发模式，处理不了服务器组件，更处理不了那些复杂的依赖项清理逻辑。
今天，我们的主角是 pushEffect。这名字听起来就像是把什么东西“推”进去了。没错，它就是负责把副作用推入调度队列的核心函数。而今天我们要死磕的重点是：这个函数是如何利用“位掩码”这种看起来像黑魔法一样的技术，精准地识别并区分 HasConfigurableSideEffects 这个标志的？
准备好了吗？让我们把键盘敲得震天响，开始这场代码的探险！
第一部分：Fiber 架构与“Flag”的哲学
在深入 pushEffect 之前，我们必须先理解 React 的“世界观”。React 的世界不是由 DOM 节点组成的，而是由 Fiber 节点组成的。
你可以把 Fiber 节点想象成一棵树的节点。每一个节点都有很多属性：
type: 指令是什么？（比如'div'）key: 它的钥匙是什么？stateNode: 它对应的 DOM 在哪里？
但今天我们要关注的是 flags。在 React 的世界里，flags 是一个数字。是的，就是一个简单的 number。
为什么要用数字？为什么要用位掩码？这就好比我们家里有很多电器，我们不想给每个电器都留一个独立的插座，那样太浪费了。我们用一个电闸（数字），通过控制不同的触点（二进制位）来控制不同的电器。
在 React 内部，有一个非常著名的“位掩码”集合。比如：
HasRef = 0x1HasContext = 0x2HasEffect = 0x4HasConfigurableSideEffects = 0x1（注意，在某些版本中它可能是0x1，或者包含在HasEffect中，具体取决于 React 的版本，但逻辑是通用的）。
HasConfigurableSideEffects 这个标志，字面意思是“具有可配置的副作用”。这是什么意思？简单来说，这意味着这个副作用是“活的”。它不是那种一旦挂载就死掉的东西，它允许 React 在更新时“重置”它、清理它、或者根据新的依赖项重新运行它。这就是 useEffect、useLayoutEffect 和 useInsertionEffect 的本质特征。
而 pushEffect，就是那个负责给副作用打上“标签”的法官。
第二部分：pushEffect 的登场
让我们直接跳进 React 的源码（ReactFiberHooks.js），看看 pushEffect 到底长什么样。为了方便理解，我稍微简化了代码结构，去掉了那些令人头秃的类型定义，保留了核心逻辑。
function pushEffect(tag, payload, next) {
// 1. 创建一个新的 Effect 对象
// 这个 Effect 对象是用户定义的副作用（比如 useEffect 里的函数）的载体
const effect = {
tag, // 标签，告诉我们这是哪种副作用
payload, // 数据载荷，比如依赖项数组
next, // 指向下一个 Effect 的指针，形成一个链表
};
// 2. 关键步骤：检查副作用类型
// 这里我们要引入“位掩码”的魔法了
// hasSideEffectMask 通常包含 HasEffect 等标志
// HasConfigurableSideEffects 是其中一个子集
const hasEffect = (tag & hasSideEffectMask) !== 0;
// 3. 如果这个 Effect 具有“可配置的副作用”标志
if (hasEffect) {
// React 需要处理它！
// 比如：它需要被加入调度队列，或者在渲染时被立即执行（如果是 useLayoutEffect）
// 或者它需要被记录下来，以便在下次渲染时进行清理（cleanup）
// 这里我们模拟一下 React 如何处理这个标志
// 实际上，React 会根据不同的 Tag（比如 useEffect, useLayoutEffect）做不同的处理
// 但核心逻辑都是：我检测到了这个标志，我就知道它需要被“配置”和“管理”
}
// 4. 将 Effect 推入 Fiber 节点的更新队列
// 这里是真正的“推”操作
// updateQueue 是一个链表，存着所有在这个组件渲染周期内产生的 Effect
if (fiber.updateQueue === null) {
fiber.updateQueue = {
baseState: null,
firstBaseEffect: null,
lastBaseEffect: null,
shared: {
pending: null,
},
effects: null, // 这里存放着所有需要被执行的 Effect
};
fiber.updateQueue.effects = [effect];
} else {
// 如果队列已经存在，就把新的 Effect 链接到队尾
const lastEffect = fiber.updateQueue.lastBaseEffect;
if (lastEffect !== null) {
lastEffect.next = effect;
} else {
fiber.updateQueue.firstBaseEffect = effect;
}
fiber.updateQueue.lastBaseEffect = effect;
}
// 5. 更新 Fiber 节点的 Flags
// 这是最重要的一步！
// React 不仅仅把 Effect 存起来，它还要告诉渲染器：“嘿，兄弟，这个节点有副作用，渲染的时候别忘了处理它！”
// 这里就利用了位掩码来区分不同的副作用类型
if ((tag & HookHasEffectMask) !== 0) {
// 如果是 useEffect 或 useLayoutEffect
// 需要标记 Fiber 节点，表示它有副作用需要执行
fiber.flags |= HasEffect;
// 关键点来了：HasConfigurableSideEffects 的区分
// 我们知道 HasConfigurableSideEffects 通常包含在 HasEffect 里
// 但 React 需要知道这个 Effect 具体是“可配置”的
// 如果这个 Effect 允许配置（比如用户写了 useEffect），我们就标记它
fiber.flags |= HasConfigurableSideEffects;
}
}第三部分：位掩码的“侦探”工作
上面的代码只是个骨架，我们来看看具体的位运算逻辑。在 React 内部，pushEffect 的工作流程是这样的：
1. 接收输入：
当你写 useEffect(() => {}, []) 时，React 会调用 pushEffect。传入的 tag 可能是 EffectTag 枚举中的一个值，比如 PerformedPassiveEffect 或 LayoutMask。
2. 位运算筛选：
pushEffect 内部会执行 (tag & hasSideEffectMask) !== 0。
- 假设
hasSideEffectMask是0x4（代表 HasEffect）。 - 假设传入的
tag是0x5（代表 HasEffect + HasRef）。 0x5 & 0x4 = 0x4，结果不为 0。React 判断：“这个 Effect 确实有副作用，必须处理。”
3. 区分 HasConfigurableSideEffects：
这是最精彩的部分。React 并不满足于知道“有副作用”，它还要知道“是什么类型的副作用”。
在 React 的源码中，HasConfigurableSideEffects 通常被定义为 0x1。它被包含在 HasEffect（0x4）中。
当 pushEffect 执行时，它会检查这个 Effect 是否属于“可配置”类别。
// React 源码逻辑简化版
if (tag & HookHasEffectMask) { // 0x1
fiber.flags |= HasEffect; // 0x4
fiber.flags |= HasConfigurableSideEffects; // 0x1
}为什么要区分它？
因为“可配置”意味着这个副作用需要被清理。
- 如果你写的是
useRef，它没有副作用，不需要清理。 - 如果你写的是
useEffect，它有副作用，而且每次更新前都需要清理上一次的副作用（调用 cleanup 函数）。 HasConfigurableSideEffects标志就是告诉渲染器：“这个副作用在下次渲染到来之前，必须先执行destroy函数，然后再执行create函数。”
这就像是给快递员发了一个特殊指令：“这个包裹里是易碎品，而且换货的时候必须先退回旧的，再发新的。” 而普通的副作用（比如 useRef 的值更新）就像是普通包裹，直接扔进去就行了，不需要退旧换新。
第四部分：代码实战与场景模拟
为了让你彻底明白，我们来模拟一个真实的场景。
场景： 你有一个计数器组件，点击按钮加 1，并打印日志。我们使用了 useEffect。
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
console.log(`Count changed to ${count}`);
const timer = setInterval(() => {
console.log(`Tick: ${count}`);
}, 1000);
// 返回 cleanup 函数
return () => {
console.log(`Cleanup: Count is now ${count}`);
clearInterval(timer);
};
}, [count]); // 依赖项是 count
return <button onClick={() => setCount(c => c + 1)}>Add</button>;
}现在，让我们跟随 pushEffect 的脚步，看看它发生了什么。
第一阶段：初次渲染
- 用户点击按钮。触发
setCount。 - 调度器工作。React 决定渲染下一帧。
pushEffect被调用。- 它接收到
tag，其中包含HasEffect和HasConfigurableSideEffects。 - 位掩码检查：
(tag & HookHasEffectMask) !== 0。结果为真。 - 设置 Flags：
fiber.flags |= HasEffect且fiber.flags |= HasConfigurableSideEffects。 - 推入队列：
effect对象被推入fiber.updateQueue.effects。
- 它接收到
- 渲染完成。React 发现
fiber.flags被修改了（有了副作用标志）。 - 提交阶段。React 遍历
fiber.flags，发现HasConfigurableSideEffects。 - 执行：React 运行
useEffect的函数。console.log打印，setInterval启动。
第二阶段：更新渲染
- 再次点击按钮。
- 触发更新。React 重新渲染组件。
pushEffect再次被调用。- 关键点来了！React 不会清除之前的
fiber.flags。它会累加标志位。 - 如果没有
HasConfigurableSideEffects，React 可能会直接跳过清理，直接覆盖。 - 但因为
HasConfigurableSideEffects存在，React 知道：“等等，这个 effect 之前运行过，现在要变了，必须先清理旧的！”
- 关键点来了！React 不会清除之前的
- 位掩码逻辑：
pushEffect再次检测到标志。- 它再次将标志位推入队列。
fiber.updateQueue现在包含了两个 Effect 对象（或者一个包含 cleanup 逻辑的新 Effect）。
- 执行：React 运行 cleanup 函数（打印
Cleanup），然后运行新的 effect（打印Count changed to 1）。
看懂了吗？HasConfigurableSideEffects 就是一个开关。 pushEffect 通过位运算 (tag & HookHasEffectMask) 识别出这个开关被打开了。一旦识别出来，它就不仅仅是把函数存起来，而是把“清理旧状态”这个复杂的逻辑也塞进了执行流程里。
第五部分：为什么不用对象，非要用位掩码？
你可能会问：“老兄，这年头谁还用位掩码啊？直接写个 if (effect.type === 'configurable') 不就行了？”
朋友，这就是专家和普通程序员的区别。React 是一个运行在浏览器沙箱里的巨型引擎，它必须精打细算。
1. 性能（CPU 缓存友好性）：
位运算是 CPU 原生支持的，速度极快。在渲染循环中，每一纳秒都至关重要。if (flags & 1) 比 if (flags.someProperty) 快得多。而且，位掩码允许 React 一次性检查多个标志：
// 检查这个节点是否同时具有 Ref 和 Context
if (fiber.flags & (HasRef | HasContext)) {
// ...
}如果用对象，你得写 if (fiber.flags.ref && fiber.flags.context)，或者遍历一个数组。位掩码是一行代码搞定所有。
2. 内存占用：
fiber.flags 只是一个整数（32位）。而如果用对象，它可能需要分配一个对象引用，增加垃圾回收的压力。在 React 这种会创建成千上万个 Fiber 节点的系统里，省下的每一字节内存都是巨大的胜利。
3. 源码的可扩展性：
React 团队非常聪明。他们把标志位定义成枚举，然后用位运算组合它们。如果以后 React 想加一个新特性，比如 HasHydrationEffect，他们只需要定义一个新的位（比如 0x8），然后在 pushEffect 里检查一下就行了，不需要修改整个逻辑结构。
第六部分：pushEffect 的完整逻辑重构
为了彻底吃透，让我们把 pushEffect 的逻辑拆得更细一点。React 的源码非常复杂，涉及大量的并发逻辑，但我们可以提取出核心的“位掩码区分逻辑”。
假设我们有一个简化版的 pushEffect：
// 定义标志位常量
const HookHasEffectMask = 0x1; // 0x1 = HasConfigurableSideEffects
const HasEffectMask = 0x4; // 0x4 = HasEffect (包含上面的)
function pushEffect(tag, payload, next) {
// 1. 创建 Effect 对象
const effect = {
tag,
payload,
next,
};
// 2. 核心判断逻辑
// React 需要知道这个 Effect 是否是“可配置的”
// 也就是是否需要执行 cleanup
const hasConfigurableSideEffect = (tag & HookHasEffectMask) !== 0;
// 3. 如果是可配置的副作用，我们需要特殊处理
if (hasConfigurableSideEffect) {
// 这里的逻辑非常关键：
// 我们不仅要把它推入队列，还要确保渲染器知道它需要被调度
// 假设这是 useEffect 或 useLayoutEffect
// React 会在这里设置一个特定的标记，告诉调度器：“这是一个需要清理的副作用”
// 在 React 源码中，这通常涉及到调用 scheduleCallback
// 但在 pushEffect 内部，主要是构建数据结构
}
// 4. 更新 Fiber 节点的 Flags
// 这是最直接的“区分”操作
// 我们通过位或运算，将标志位“烙印”在节点上
if (hasConfigurableSideEffect) {
fiber.flags |= HookHasEffectMask;
}
// 5. 将 Effect 推入队列
// 这里我们使用链表结构
const updateQueue = fiber.updateQueue;
if (updateQueue === null) {
fiber.updateQueue = {
baseState: null,
firstBaseEffect: null,
lastBaseEffect: null,
shared: { pending: null },
effects: null,
};
fiber.updateQueue.effects = [effect];
} else {
// 链接
const lastEffect = updateQueue.lastBaseEffect;
if (lastEffect === null) {
updateQueue.firstBaseEffect = effect;
} else {
lastEffect.next = effect;
}
updateQueue.lastBaseEffect = effect;
}
}在这个逻辑中，pushEffect 就是那个位掩码的执行者。
它接收一个 tag（通常来自 Hooks 的实现，比如 useEffect 会传入特定的 tag 值）。
它使用 & 运算符提取出 HookHasEffectMask。
如果提取成功（结果不为 0），它就确认：“这是一个 useEffect 或 useLayoutEffect”。
然后，它利用 |= 运算符，把这个确认结果写死在 fiber.flags 上。
第七部分：深入 HasConfigurableSideEffects 的含义
让我们把镜头拉远，看看这个标志在整个 React 生命周期中的角色。
1. 区分“副作用”与“状态”：
React 的核心是 Diff 算法，它关注的是 UI 的变化。useRef 虽然有副作用（修改 DOM），但它不改变视图，所以它不需要 HasConfigurableSideEffects。只有 useEffect 和 useLayoutEffect 这种会改变视图（通过副作用）且可能需要清理的，才拥有这个标志。
2. 决定渲染顺序：
在并发模式下，渲染可能被中断、恢复、丢弃。
- 如果一个 Fiber 节点没有
HasConfigurableSideEffects，React 可能会直接跳过它的渲染，因为它不产生视觉变化。 - 如果有这个标志，React 就必须保证它在正确的时机被渲染，并且在渲染前执行 cleanup，渲染后执行 effect。
3. 与 useInsertionEffect 的关系：
useInsertionEffect 也是可配置的副作用。它比 useEffect 先执行，比 useLayoutEffect 后执行。pushEffect 在处理 useInsertionEffect 时，也会设置 HasConfigurableSideEffects，但会根据特定的 tag 逻辑，将其插入到不同的执行队列中。
第八部分：总结与回顾
好了，各位同学，我们今天的代码探险即将结束。
让我们回顾一下 pushEffect 是如何利用位掩码区分 HasConfigurableSideEffects 的：
- 输入识别：
pushEffect接收一个带有tag的 Effect 对象。 - 位运算筛选：它使用
tag & HookHasEffectMask。这就像是用一把钥匙（掩码）去匹配门锁（tag）。 - 逻辑分支：如果匹配成功（返回非零值），它就确认这是一个“可配置的副作用”。
- 状态标记：它使用
fiber.flags |= HookHasEffectMask，把这个确认信息永久地标记在 Fiber 节点上。 - 数据入队：它把这个 Effect 对象推入
fiber.updateQueue的链表中。
这个过程非常高效、紧凑，而且逻辑严密。React 就是这样，用最简单的二进制逻辑（0 和 1），构建出了最复杂的异步 UI 系统。
为什么我们需要 HasConfigurableSideEffects？
因为它告诉 React：“嘿，这个 effect 不是一次性用品，它是消耗品。每次更新，它都会消耗掉旧的（cleanup），然后生产出新的。请务必在它消失之前妥善处理它。”
这就是 pushEffect 的智慧。它不仅仅是在推入数据，它是在管理 React 应用的状态机。它通过位掩码这种看似枯燥的技术，实现了对副作用生命周期的精细控制。
希望今天的讲座能让你对 React 内部机制有一个全新的认识。下次当你写下 useEffect 时，请记住那个在后台默默工作的 pushEffect 函数，以及它手中那把神奇的位掩码钥匙。
下课！代码敲起来！