React 副作用标志位 Flags 位运算逻辑

各位同学，大家好！

今天我们不聊 useEffect 的依赖数组，也不聊 React.memo 的浅比较，更不聊那些让你抓耳挠腮的闭包陷阱。我们要把目光投向 React 的“后台”——那个只有最核心的开发者才敢轻易触碰的神秘角落。

今天，我们要深入探讨的是 React 的副作用标志位。

如果你是一名 React 开发者，你可能写过成千上万行代码，但你可能从来没见过这些标志位长什么样。它们不是 DOM，不是 State，也不是 Context。它们是数字。是那些在十六进制世界里闪烁的 0x01、0x02、0x04。

很多人觉得 React 的渲染流程像是一个魔法盒子，你往里扔一个对象，它就吐出一个页面。但实际上，React 内部有一个庞大的、精密的调度系统，而在那个调度系统的核心，就是这些Flag。

想象一下，React 就像一个极度忙碌的管家，面前有成千上万个组件。他不可能对每一个组件都大喊大叫说：“嘿，你变了！你变了！你还没变！你没了！”

太累了，效率太低。

所以，管家发明了一个位运算系统。他给每个组件发了一张“便利贴”，上面写着数字。如果这张便利贴是 0x01，就代表“插入”；如果是 0x02，就代表“更新”。如果便利贴是 0x03（即 0x01 | 0x02），那就代表“既插入了，又更新了”。

这就是我们今天要聊的——React 副作用标志位。

---

第一部分：Fiber 架构与“便利贴”哲学

在 React 16 之前，React 的渲染是同步的。这就像是在煮一锅水，如果水开了（组件渲染时间过长），整个页面就会卡死，浏览器窗口会直接变成白板，直到这锅水煮完。

为了解决这个问题，React 团队搞出了 Fiber 架构。Fiber 不仅仅是一个架构，它更像是一个链表结构。

你可以把 React 的组件树想象成一座大城堡。在 Fiber 架构下，这座城堡被拆解成了一个一个的“房间”，每个房间都有一个编号，我们称之为 Fiber Node。

每个 Fiber Node 都长这样：

// 这是一个简化版的 Fiber 结构
const fiber = {
  type: 'button',
  stateNode: document.createElement('button'), // 挂载的 DOM 节点
  return: fiberNodeParent, // 指向父节点
  child: fiberNodeFirst,   // 指向第一个子节点
  sibling: fiberNodeNext,  // 指向下一个兄弟节点
  // 重点来了！
  flags: 0,                // 副作用标志位，初始为 0
  memoizedState: null,
  updateQueue: null,
};

注意那个 flags: 0。初始状态下，这个组件是“安静”的，什么都没做。

但是，当父组件发生变化，或者父组件重新渲染时，React 需要知道这个子组件该做什么。是直接扔进垃圾桶（卸载）？还是像个老朋友一样握手（更新）？还是它本来就在那儿，只是动了一下（插入）？

为了回答这个问题，React 会在协调阶段（Reconciliation Phase）修改这个 flags 的值。

这就是“便利贴哲学”：不要在渲染过程中去执行复杂的副作用，先把副作用记录下来，等渲染完了再统一处理。

---

第二部分：位运算的奥义（1, 2, 4, 8…）

要理解 Flags，我们必须先理解位运算。这听起来很吓人，但其实很简单，这就是计算机的“开关”。

在计算机内存里，所有的数据最终都是二进制。二进制就是一堆 0 和 1。

• 1 代表有电。
• 0 代表没电。

如果我们想表示“我有电”，我们可以写 0b1。
如果我们想表示“我有电，而且我也亮着灯”，我们可以写 0b11。

在 React 源码中，Flags 被定义为一系列的常量。为什么是常量？为了方便记忆和运算。

// ReactFiberFlags.js (伪代码)

// 0x1 是二进制的 0001
// 这意味着最低位是 1。
export const Placement = 0x01; 
// 含义：这是一个新插入的节点。就像你在新装修的房间里贴了一张“新”标签。

// 0x2 是二进制的 0010
// 这意味着第二位是 1。
export const Update = 0x02; 
// 含义：这个节点的 State 发生了变化，需要更新 DOM。

// 0x4 是二进制的 0100
export const Deletion = 0x04;
// 含义：这个节点要被删除了。

// 0x8 是二进制的 1000
export const ContentReset = 0x08;
// 含义：内容重置（比较少见，但存在）。

// 0x20 是二进制的 0010 0000
export const Passive = 0x20;
// 含义：这是一个被动副作用。比如 useEffect 的清理函数或者更新回调。
// 注意这里的 0x20，它是跳过了 0x10（虽然源码里可能有其他标志位），直接到了 32 的位置。

为什么是十六进制？因为十六进制（以 0x 开头）读起来很像二进制。0x20 直接对应二进制的 0010 0000，非常直观。

---

第三部分：如何设置 Flags（按位或运算）

现在，假设 React 的调度器发现父组件变了，它开始遍历子组件树。在遍历的过程中，它发现了一个子组件 Button，它的 props.onClick 变了。

React 决定：更新这个按钮！

在代码里，这通常是这样的逻辑：

function reconcileChildren(currentFiber, workInProgressFiber) {
  // ... 省略前面的 diff 算法逻辑 ...

  // 假设我们 diff 出来发现需要更新
  if (shouldUpdate) {
    // 核心操作：按位或运算 (|)

    // workInProgressFiber.flags 是当前正在构建的 Fiber 节点
    // 我们把 'Update' 标志位加进去

    workInProgressFiber.flags |= Update;
  }
}

按位或运算 | 的逻辑是：
如果某一位是 0，变成 1；如果某一位已经是 1，保持 1。

假设 workInProgressFiber.flags 初始是 0（全 0）。
执行 flags |= Update（即 flags |= 0x02）。
计算过程：
0 (二进制 0000)
| (按位或)
0x02 (二进制 0010)

0x02 (二进制 0010)

结果：flags 变成了 2。

如果 flags 初始是 0x01（表示它原本是 Placement）。
执行 flags |= Update。
计算过程：
0x01 (二进制 0001)
| (按位或)
0x02 (二进制 0010)

0x03 (二进制 0011)

结果：flags 变成了 3。

这意味着什么？
这意味着这个组件既被插入了，又被更新了。

在 React 内部，这是一个非常高效的操作。它不需要创建一个新的对象，也不需要复制数组。它只是在一个整数上，把对应的“灯泡”给点亮了。

---

第四部分：如何读取 Flags（按位与运算）

光有设置还不行，我们还得知道怎么读。比如在提交阶段（Commit Phase），React 需要把这些变更应用到真实的 DOM 上。

React 会遍历 Fiber 树，然后检查每个节点：

function commitWork(fiber) {
  // 1. 检查是否有副作用
  // 如果 flags 是 0，那就什么都不做，继续下一个

  if ((fiber.flags & Placement) !== 0) {
    // 2. 按位与运算 (&)
    // 逻辑：如果 flags 的最低位是 1，那么结果就是 1 (非 0)，否则是 0。

    commitPlacement(fiber); // 执行插入 DOM 的逻辑
  }

  if ((fiber.flags & Update) !== 0) {
    commitUpdate(fiber); // 执行更新 DOM 的逻辑
  }

  if ((fiber.flags & Deletion) !== 0) {
    commitDeletion(fiber); // 执行删除 DOM 的逻辑
  }
}

按位与运算 & 的逻辑是：
如果某一位是 1，且另一边也是 1，结果才是 1。

假设 flags 是 0x03（二进制 0011）。
检查 Placement (0x01, 二进制 0001)：
0x03 & 0x01 = 0x01 (非 0) -> 是 Placement！

检查 Update (0x02, 二进制 0010)：
0x03 & 0x02 = 0x02 (非 0) -> 是 Update！

检查 Deletion (0x04, 二进制 0100)：
0x03 & 0x04 = 0x00 (0) -> 不是 Deletion！

这就是位运算的强大之处。它就像是一个过滤器，我们可以同时检查多种状态，而不需要写一堆 if else。

---

第五部分：深入解析具体标志位

让我们来逐一认识一下 React 里的这些“大人物”。

1. Placement (0x01) – 插入

这是最简单的一个。当一个组件在父组件的列表中从“无”变成了“有”，或者从“有”移动到了新的位置，React 就会打上这个标记。

代码示例：

// 假设我们正在 diff 列表
const oldFiber = null; // 父节点没有旧的孩子
const newFiber = {
  type: 'li',
  flags: 0
};

// React 发现：没有旧的了，需要新建一个！
newFiber.flags |= Placement; 
// 现在 newFiber.flags = 0x01

2. Update (0x02) – 更新

这是最常见的一个。父组件重新渲染了，传递了新的 props，或者 state 发生了变化。

const oldFiber = { memoizedProps: { color: 'red' } };
const newFiber = { 
  memoizedProps: { color: 'blue' },
  flags: 0 
};

// 颜色变了
newFiber.flags |= Update; 
// 现在 newFiber.flags = 0x02

3. Deletion (0x04) – 删除

当我们在列表中删除了一个元素，React 不会立即删除 DOM。它会打上这个标记。然后 React 会遍历完整棵树，最后统一执行删除操作。这叫做批量处理。

const oldFiber = { ... };
const newFiber = null; // React 发现这个位置现在没有新节点了

// 标记删除！
if (oldFiber) {
  // 旧 Fiber 节点需要被移除
  // 我们通常在 workInProgress 树上标记 oldFiber 的 flags
  // 或者是 workInProgress 的 sibling 指向下一个
  // 但核心逻辑里，Deletion 标志位会附着在某个 Fiber 上
}

4. Passive (0x20) – 被动副作用

这是一个比较特殊的标志位。它不直接操作 DOM（不像 Placement 或 Update），而是操作副作用。

在 React 18 之前，useEffect 的回调函数是在提交阶段执行的。但在 18 之后，为了优化性能，useEffect 被移到了调度阶段，也就是在渲染阶段（调度阶段）就开始执行了。

但是，如果是在渲染阶段执行，就不能打断渲染。所以 React 把 useEffect 分为了两种：

1. 被动副作用：普通的 useEffect。在渲染阶段执行，打上 Passive 标记。
2. 同步副作用：useLayoutEffect。在提交阶段执行，不打这个标记。

当渲染完成，React 会检查带有 Passive 标记的节点，然后调用 schedulePassiveEffects，去执行那些副作用。

// React 内部逻辑
if (hasPassiveEffectDependencies) {
  workInProgress.flags |= Passive;
}

5. Snapshot (0x08) – 快照

这个标志位比较神秘。它通常出现在 useEffect 的依赖变化，并且 React 需要执行清理函数的时候。

当 React 准备执行 useEffect 的清理逻辑时，它会打上这个标记。这就像是告诉调度器：“嘿，在渲染完之后，先别急着提交，先把这个组件的旧状态保存一下，我要用。”

6. Hydration (0x20) – 水合

这是一个 SSR（服务端渲染）相关的标志位。

当你从服务端获取了 HTML，然后 React 需要把这些 HTML 和客户端的 DOM 进行比对。这个过程叫“水合”。

如果 React 发现服务端的 HTML 和客户端的 JSX 结构不一致，它就会打上 Hydration 标记。

// React 内部逻辑
if (serverHtml !== clientHtml) {
  fiber.flags |= Hydration;
}

---

第六部分：复杂组合与位移

React 的 Flags 逻辑非常灵活。一个 Fiber 节点可能同时拥有多个标志位。

场景：列表重排
假设你有一个列表 [A, B, C]。
你把 B 移到了最前面，变成了 [B, A, C]。

React 的 diff 算法会怎么做？

1. 它发现 B 在新列表里，也在旧列表里。但是位置变了。-> 标记 Update。
2. 它发现 A 还在，位置变了。-> 标记 Update。
3. 它发现 C 还在，位置没变。-> 不标记。

所以 B 的 flags 可能是 0x02，A 的 flags 可能是 0x02。

场景：列表增删
假设你有一个列表 [A, B, C]。
你删除了 B，变成了 [A, C]。

React 的 diff 算法会怎么做？

1. A 还在。-> 标记 Update。
2. B 没了。-> 标记 Deletion。
3. C 还在。-> 标记 Update。

所以 A 的 flags 是 0x02，B 的 flags 是 0x04，C 的 flags 是 0x02。

---

第七部分：如何调试 Flags（十六进制的艺术）

如果你在 React 源码里打断点，你会看到很多 0x01、0x02 之类的数字。初学者看到这些可能会头大。但如果你懂了位运算，这些数字就是世界上最美的代码。

让我们来做一个练习。假设你看到某个 Fiber 节点的 flags 是 0x41。

console.log(flags); // 65
console.log(flags.toString(2)); // "1000001"
console.log(flags.toString(16)); // "41"

0x41 是二进制的 0100 0001。

这意味着：

1. 第 0 位是 1：它是 Placement（插入）。
2. 第 6 位是 1：它是 Snapshot（快照）。

这个组件既被插入了，又需要快照。

这通常发生在什么情况下？
想象一下，你有一个列表，你通过 useState 添加了一个新元素。React 会把这个新元素插入到列表末尾（Placement），同时因为状态改变了，React 可能需要为 useEffect 准备清理逻辑（Snapshot）。

所以，0x41 并不是乱码，它是 React 给我们写的一封情书，用二进制代码写着：“我爱你，我要插入你，并且我需要记住现在的状态。”

---

第八部分：为什么不用数组或对象？

你可能会问：“为什么 React 不直接用 flags: { placement: true, update: false } 呢？这样不更直观吗？”

这就要说到性能和内存了。

1. 内存占用：一个布尔对象在内存中需要占用额外的空间（引用、属性名等）。而一个整数只需要 4 个字节（在 32 位系统上）或者 8 个字节。在 React 需要处理成千上万个 Fiber 节点的时候，这种微小的优化会累积成巨大的性能提升。
2. 位运算速度：现代 CPU 对位运算的支持非常好。| 和 & 指令非常快，比创建和遍历对象要快得多。
3. 压缩性：整数可以被压缩。在 React 的源码中，flags 有时会被压缩存储，或者与其他属性共享同一个变量（虽然这比较少见，通常 flags 是独立的）。

---

第九部分：React 18 的并发特性与 Flags

React 18 引入了并发特性，比如 useTransition 和 useDeferredValue。这对 Flags 产生了什么影响？

自动批处理（Automatic Batching）
在 React 17 及以前，你在事件处理函数里连续调用两次 setState，只会触发一次渲染。

function handleClick() {
  setCount(c => c + 1); // 触发渲染
  setCount(c => c + 1); // 被合并，不触发渲染
}

在 React 18 中，这个逻辑变了。即使是在事件处理函数里，React 也会自动批处理。这意味着你的 Flags 逻辑变得更复杂了。

React 必须更聪明地管理 Flags。因为并发渲染允许 React 暂停一个渲染任务，去处理另一个优先级更高的任务。

如果 React 正在渲染任务 A，然后把 Flags 标记为 Update，然后暂停了。此时任务 B 开始渲染，它可能也会修改同一个组件的 Flags。

React 需要在这些 Flags 上做“合并”和“去重”。它不能简单地累加，因为 Update 和 Update 叠加还是 Update。React 内部有一套复杂的逻辑来处理这些并发更新，确保最终的 Flags 是正确的。

---

第十部分：实战演练——模拟一个简单的 Reconciler

让我们来写一个极其简化的、模拟 React Flags 逻辑的 Reconciler。这能让你彻底理解这些标志位是如何流转的。

// 1. 定义 Flags 常量
const Flags = {
  Placement: 0x01, // 0001
  Update:    0x02, // 0010
  Deletion:  0x04, // 0100
};

// 2. 定义 Fiber 节点类
class FiberNode {
  constructor(type) {
    this.type = type;
    this.flags = 0; // 初始无副作用
    this.nextEffect = null; // 用于连接带有副作用的节点
  }
}

// 3. 模拟 Diff 算法（简化版）
function reconcile(diffList, oldFiberList) {
  // 这是一个非常简化的 diff 逻辑，仅用于演示
  const results = [];

  // 假设我们比较新旧列表，发现第一个元素变了
  // 比如旧的是 <div>Old</div>，新的是 <div>New</div>

  if (diffList.length > 0 && oldFiberList.length > 0) {
    const newNode = new FiberNode('div');
    newNode.flags |= Flags.Update; // 标记为更新
    results.push(newNode);
  }

  // 假设我们在列表末尾添加了一个 <span>New Item</span>
  if (diffList.length > oldFiberList.length) {
    const newNode = new FiberNode('span');
    newNode.flags |= Flags.Placement; // 标记为插入
    results.push(newNode);
  }

  // 假设我们删除了中间的一个元素
  if (oldFiberList.length > diffList.length) {
    // 在真实 React 中，删除的节点通常标记在 workInProgress 树的 sibling 链上
    // 这里我们简单演示一下 Deletion 标记
    const deleteNode = new FiberNode('div');
    deleteNode.flags |= Flags.Deletion; // 标记为删除
    // 注意：真实 React 中，删除节点通常不需要在节点上打 Deletion 标记，
    // 而是通过 Fiber 树的结构变化来指示。这里仅为概念演示。
  }

  return results;
}

// 4. 提交阶段：执行副作用
function commitEffects(fiberList) {
  fiberList.forEach(fiber => {
    if ((fiber.flags & Flags.Placement) !== 0) {
      console.log(`[Commit] 插入节点: <${fiber.type}>`);
      // createDOM(fiber);
    }
    if ((fiber.flags & Flags.Update) !== 0) {
      console.log(`[Commit] 更新节点: <${fiber.type}>`);
      // updateDOM(fiber);
    }
    if ((fiber.flags & Flags.Deletion) !== 0) {
      console.log(`[Commit] 删除节点: <${fiber.type}>`);
      // removeDOM(fiber);
    }
  });
}

// --- 运行演示 ---

const oldList = [
  new FiberNode('div') // <div>Old</div>
];

const newList = [
  new FiberNode('div'), // <div>New</div> (更新)
  new FiberNode('span') // <span>Item</span> (插入)
];

console.log("--- 开始 Reconcile ---");
const workInProgressList = reconcile(newList, oldList);

console.log("n--- 开始 Commit ---");
commitEffects(workInProgressList);

输出结果：

--- 开始 Reconcile ---

--- 开始 Commit ---
[Commit] 更新节点: <div>
[Commit] 插入节点: <span>

看！这就是 React 内部的工作流。没有任何魔法，只有标志位、位运算和循环。

---

第十一部分：总结与反思

讲到这里，我们大概已经摸清了 React 副作用标志位的门道。

Flags 是 React 的“工作日志”。当 React 协调器（Scheduler + Reconciler）发现组件树发生了变化，它不会立刻去操作 DOM，而是给每个受影响的节点打上一个个小旗子。

• 0x01 (Placement) 是“新建”。
• 0x02 (Update) 是“修改”。
• 0x04 (Deletion) 是“销毁”。
• 0x20 (Passive) 是“后台任务”。

通过位运算（| 和 &），React 以一种极其高效、紧凑的方式记录了整个应用的变更历史。

理解这些 Flags，能让你在遇到 React 性能问题时，不再只是盲目地 console.log，而是能够通过阅读源码，理解为什么某个组件会触发多次渲染，或者为什么某个副作用没有按预期执行。

最后，我想说，编程不仅仅是写业务逻辑，更是理解底层的运行机制。当你看到 0x01 这个数字时，不要害怕。它是 1，是 true，是“开始”，是“行动”。它是 React 生命力的源泉，是它让我们的应用在浏览器中活蹦乱跳的原因。

好了，今天的讲座就到这里。希望大家以后再看到 Flags 时，能会心一笑，就像看到老朋友一样。下课！

---

(附录：常见 Flags 值速查表)

为了方便大家复习，这里列出 React 源码中常见的一些 Flags 值及其含义（基于 React 18）：

标志位 (Hex)	二进制	十进制	常量名	含义
0x01	0001	1	Placement	插入新节点
0x02	0010	2	Update	更新节点
0x04	0100	4	Deletion	删除节点
0x08	1000	8	ContentReset	内容重置
0x10	1 0000	16	Callback	回调副作用
0x20	10 0000	32	Passive	被动副作用
0x40	100 0000	64	Snapshot	快照
0x80	1000 0000	128	HasEffect	有副作用（通用）
0x100	1 0000 0000	256	Hydrating	水合中 (SSR)

希望这份讲座能让你对 React 内部机制有更深的理解。下次写代码时，别忘了给那些默默工作的 Flags 点个赞！