深入 React 并发模式：当“分身术”遇上 Context 栈

各位同学，大家好！欢迎来到今天的 React 源码深度剖析课。

咱们今天不聊高深莫测的架构设计，也不谈那些飘在天上的设计模式。咱们聊点实实在在、甚至有点“血腥”的东西。在 React 18 引入并发模式之前，Context 就像个老实巴交的邮递员，递给你一个包裹，你拿走了，完事。但在并发模式下，这个邮递员变得神出鬼没，他可能在你手伸出去之前换了个包裹，也可能在你读完第一页信纸时突然换了个新版本。

这就是我们今天要聊的主题：React 并发模式下的 Context 值污染问题，以及源码是如何像玩俄罗斯套娃一样，确保每个渲染分片都能读取到正确的 Provider 栈值的。

准备好了吗？咱们把咖啡泡好，把键盘敲响，开始这场源码之旅。

---

第一部分：并发模式下的“分身术”

首先，咱们得搞清楚什么是并发模式。在 React 18 之前，渲染就像是在一条单行道上开车，不管前面是红灯还是堵车，你都得往前走，直到把这一页画完。

但在并发模式下，React 采用了时间切片技术。它把一次漫长的渲染任务切碎了，切成了无数个微小的“分片”。就像一个厨师（渲染器）在做满汉全席，他不能一口把菜全做完，他得切菜、炒菜、装盘，切完一盘再切一盘。

这就带来了一个巨大的问题：上下文切换。

想象一下，你在做菜（渲染组件 A），你拿起了一个盘子（Provider A），往里面放了一块肉（Context 值 1）。这时候，React 说：“嘿，别放肉了，这块肉太老了，换成牛肉（Provider A 值 2）。” 于是，你把盘子里的肉倒掉，放上了牛肉。

这时候，React 又说：“好了，继续做菜（组件 B），你手里拿的是什么？”

如果你是个新手，你可能会说：“我手里拿的是牛肉。” —— 这就对了。

但如果你是一个并发分片，情况就复杂了。假设你正在做菜 A 的第一个分片，你把牛肉放进去了。然后 React 突然打断你，让你去切菜（渲染组件 B）。在切菜的过程中，Provider A 又变了，变成了羊肉。

当你切完菜回来，继续做菜 A 的第二个分片时，你手里拿的是什么盘子？是牛肉，还是羊肉？

如果 React 没有做好管理，你可能会在同一个渲染周期内，看到“牛肉”和“羊肉”混在一起。这就是所谓的 Context 值污染。

---

第二部分：Context 的“栈”机制

为了防止这种混乱，React 内部维护了一个栈。这可不是普通的栈，这是一个专门用来存储上下文信息的“俄罗斯套娃”。

在源码中，React 使用了两个核心游标来操作这个栈：

1. contextStackCursor：指向当前上下文对象的栈。
2. valueStackCursor：指向当前上下文值的栈。

每当一个 Provider 出现，React 就会把这个 Provider 的值“压入”栈中；每当 Provider 结束，React 就会把这个值“弹出”栈。

这个机制的核心思想是：作用域。

---

第三部分：源码解剖 —— pushProvider 与 popProvider

咱们来看看源码是怎么干的。在 ReactFiberContext.js 中，有两个非常关键的函数：pushProvider 和 popProvider。

1. pushProvider：压入正确的值

当一个 Provider 组件开始渲染时，pushProvider 被调用。它的任务很简单：把当前 Provider 的值压入栈，并更新全局的 _currentValue。

function pushProvider(providerFiber, nextValue) {
  // 1. 获取当前上下文对象
  const context = providerFiber.type._context;

  // 2. 关键步骤：保存旧值
  // React 并发模式下，栈里肯定有东西，因为这是嵌套的
  const prevValue = readContext(context);

  // 3. 更新全局状态
  // 这一步很重要，它告诉所有在这个 Provider 下方的组件：
  // “嘿，我现在给你们提供的新值是 nextValue，旧值是 prevValue。”
  context._currentValue = nextValue;

  // 4. 压入栈中
  // 把 Provider 的值压入栈，这样下方的组件 readContext 时就能拿到它
  push(valueStackCursor, nextValue, context);

  // 5. 压入 Provider 对象（虽然这里代码简化了，但逻辑类似）
  push(contextStackCursor, context, providerFiber);

  // 6. 设置依赖标记
  // 这是一个性能优化点，告诉 React：“这个组件依赖于这个 Context”
  providerFiber.dependencies = {
    lanes: NoLanes,
    firstContext: context
  };
}

这段代码干了什么？
它把 Provider 的值压入了栈顶。此时，栈的结构大概是：
[旧值, 旧值, ..., Provider的新值]。

2. popProvider：恢复现场

当 Provider 渲染结束时，popProvider 被调用。它的任务是把刚才压入的值弹出来，恢复到 Provider 之前的状态。

function popProvider(providerFiber) {
  // 1. 弹出 Provider 对象
  const context = pop(contextStackCursor, providerFiber);

  // 2. 弹出 Provider 的值
  const prevValue = pop(valueStackCursor);

  // 3. 恢复全局状态
  // 把 _currentValue 改回 Provider 父级或者全局的默认值
  context._currentValue = prevValue;
}

这段代码干了什么？
它把栈顶的 nextValue 弹出去了。栈的结构变回了：
[旧值, 旧值, ...]。

---

第四部分：readContext —— 消费者的“读心术”

那么，底层的组件（Consumer）是如何读取值的呢？它调用的是 readContext。

function readContext(context, observedBits) {
  // 1. 读取栈顶的值
  // 注意，它不是去读 context._currentValue，而是去读栈！
  // 这就是并发模式的核心：栈保证了局部作用域。
  const value = readCurrentContext(context);

  // 2. 检查依赖关系
  // 如果这个组件是首次读取这个 Context，React 会标记它为依赖
  // 这就是为什么修改 Context 值不会导致所有组件重渲染的原因。

  return value;
}

这里有个巨大的坑（也是并发模式的精髓）：

如果在一个渲染分片中，你读取了 Context A 的值。然后，在渲染分片的中间，Context A 的值变了。React 会怎么处理？

如果 Context A 是“脏”的，React 会重新调度这个组件的渲染。但是，readContext 读取的是栈顶的值。

在并发模式下，栈是动态变化的。
假设你正在渲染组件 A，组件 A 读取了 Context A（值 1）。
然后，组件 A 渲染组件 B。组件 B 读取了 Context B（值 2）。
在读取 Context B 的时候，Context A 的值变为了 3。

此时，栈的结构是：
[值 1, 值 2]。
栈顶是 值 2。

如果你在组件 B 里调用 readContext(Context A)，你读到的是 值 2 吗？不对！你读到的是栈顶相对于 Context A 的位置。

React 的栈实现非常巧妙。它维护的是相对于每个 Context 对象的栈。

当你调用 readContext(Context A) 时，React 会遍历 Context A 的栈。如果栈顶是 值 2，但 值 2 并不是 Context A 的值，React 会继续往下找，直到找到 Context A 对应的那个值。

这确保了：

• 在 Provider A 的作用域内，组件永远能读到 Provider A 的值。
• 即使 Provider A 的值在渲染过程中变了，只要组件在 Provider A 里面，它就能读到最新的值（或者根据 lastContextDependency 的逻辑，读到正确的旧值）。

---

第五部分：实战演练 —— 脏检查与 lastContextDependency

光说不练假把式。咱们来写个例子，模拟一下并发渲染中可能出现的混乱场景。

场景设定

• App：提供 ThemeContext（值为 “Dark”）。
• Header：读取 ThemeContext。
• Content：提供 UserContext（值为 “Alice”）。
• Article：读取 UserContext。

代码示例

const ThemeContext = React.createContext('Light');
const UserContext = React.createContext('Guest');

function App() {
  return (
    <ThemeContext.Provider value="Dark">
      <Header />
      <Content />
    </ThemeContext.Provider>
  );
}

function Header() {
  const theme = React.useContext(ThemeContext);
  console.log("Header 读取 Theme:", theme); // 应该是 "Dark"
  return <div>Theme: {theme}</div>;
}

function Content() {
  const [user, setUser] = React.useState('Alice');

  return (
    <UserContext.Provider value={user}>
      <Article />
    </UserContext.Provider>
  );
}

function Article() {
  const user = React.useContext(UserContext);
  console.log("Article 读取 User:", user); // 应该是 "Alice"
  return <div>User: {user}</div>;
}

并发模式下的“惊魂时刻”

现在，我们开启并发模式（虽然上面的代码看不出并发，但让我们模拟一下 React 的内部逻辑）。

1. 初始渲染：

   • React 开始渲染 App。
   • ThemeContext 压入 “Dark”。
   • Header 读取 ThemeContext -> “Dark”。栈：[Dark]。
   • Content 渲染。UserContext 压入 “Alice”。
   • Article 读取 UserContext -> “Alice”。栈：[Dark, Alice]。
   • Article 渲染完毕。UserContext 弹出 “Alice”。栈：[Dark]。
   • Header 渲染完毕。ThemeContext 弹出 “Dark”。栈：[]。

2. 并发更新：

   • 用户点击按钮，setUser('Bob')。
   • React 开始重新渲染。这次是并发模式，渲染被切分了。
   • 分片 1：渲染 App。ThemeContext 压入 “Dark”。
   • 分片 2：渲染 Content。UserContext 压入 “Bob”。
   • 分片 3：渲染 Article。Article 调用 readContext(UserContext)。
     • 此时栈是 [Dark, Bob]。
     • readContext 检查栈顶，发现是 Bob。读取成功！
     • Article 渲染输出 “User: Bob”。

3. 值污染的假象：

   • 假设此时 ThemeContext 的值在全局被修改成了 “Light”（这是一个非常激进的假设，通常 Provider 不会在渲染过程中修改自己）。
   • 如果 Header 还没渲染完（分片 1 还没回来），Header 调用 readContext(ThemeContext)。
   • 栈是 [Dark, Bob]。
   • readContext 寻找 ThemeContext。它发现栈顶 Bob 不是 ThemeContext。
   • 它继续往下找，找到了 Dark。
   • 所以 Header 读到了 Dark。
   • 结论：即使在并发模式下，只要栈结构正确，组件永远能读到它“应该”读到的值，而不是栈顶的值。

防止过度渲染：lastContextDependency

这是 React 源码中最精彩的部分。如果栈能保证读到正确的值，那为什么修改 Context 不会导致所有组件重渲染？

答案是 lastContextDependency。

在 readContext 函数中，React 会检查当前组件是否已经“记录”了它对这个 Context 的依赖。

function readContext(context, observedBits) {
  // ... 读取栈的逻辑 ...

  // 如果当前组件还没记录对这个 Context 的依赖
  if (fiber.dependencies == null) {
    // 那就记录下来！
    // fiber.dependencies.firstContext 指向这个 context 对象
    fiber.dependencies = {
      lanes: NoLanes,
      firstContext: context,
    };
  }

  return value;
}

这意味着什么？

• 如果你只读取了一次 Context，React 就会记住：“哦，这个组件依赖这个 Context。”
• 当这个 Context 的值改变时，React 会检查：“这个组件依赖的这个 Context 变了吗？”
• 如果没变，React 就不会把这个组件加入重渲染队列。

如果 Context 污染了怎么办？
如果在并发渲染中，Context 的值变了，但你的组件没有依赖它，React 就不会让你重新渲染。这就是所谓的“脏检查”。

---

第六部分：源码中的“指针”与“游标”

为了让你更深入地理解，咱们再聊聊源码里那些冷冰冰但精妙的“指针”。

React 使用了 createCursor 来创建栈游标。

function createCursor(defaultValue) {
  return {
    current: defaultValue,
  };
}

在 ReactFiberContext.js 的顶部，你会看到这样两行代码：

const contextStackCursor = createCursor(null);
const valueStackCursor = createCursor(null);

这两个游标就像两根手指，指着栈的顶部。

当 pushProvider 被调用时，它会执行这样的逻辑：

function push(cursor, value, context) {
  // 1. 保存当前的栈顶指针（也就是手指现在的位置）
  const previous = cursor.current;

  // 2. 把栈顶指针往下移一格（指向新的栈顶）
  cursor.current = previous === null ? value : { baseValue: previous.baseValue, next: value };

  // ... (这里简化了栈的实现，实际源码可能更复杂，涉及 baseValue 和 next 的链表结构，以支持并发更新)
}

为什么这么复杂？
因为在并发模式下，cursor.current 可能会在渲染过程中被多个分片同时修改。如果只是一个简单的数组，一个分片 push，另一个分片 pop，就会导致数据错乱。

React 使用了类似链表的结构来模拟栈。next 指向下一个元素。

当你 pop 的时候：

function pop(cursor, context) {
  // 1. 弹出栈顶元素
  const prev = cursor.current.next;

  // 2. 恢复指针
  cursor.current = prev;

  // 3. 返回被弹出的值
  return prev.baseValue;
}

这种设计保证了即使在极端的并发场景下（比如一个分片在 push，另一个分片在 pop），栈的完整性也不会被破坏。

---

第七部分：总结与思考

好了，咱们回顾一下。在并发模式下，Context 值污染是一个巨大的隐患。

React 通过以下几招“防身术”解决了这个问题：

1. 栈结构隔离：利用栈的“后进先出”特性，确保每个组件只能访问到它作用域内的 Provider 值。readContext 不是去读全局变量，而是去读栈顶相对于自己的值。
2. 链表式栈：在源码实现中，使用了链表结构来维护栈，避免了简单的数组操作在并发读写时可能出现的竞争条件。
3. 依赖追踪：通过 lastContextDependency，React 建立了组件与 Context 的单向依赖关系。这不仅是防止值污染，更是防止过度渲染的基石。

那污染到底是怎么发生的？

通常情况下，污染发生在开发者错误地使用了 Context。
例如，你在 Provider 内部直接修改了 Context 的值，而不是创建一个新的对象。

// 错误示范
function MyComponent() {
  const context = useContext(MyContext);

  // 危险！这会污染栈！
  context.value = "New Value"; 

  return <div>{context.value}</div>;
}

或者，你在 Provider 的渲染过程中，修改了兄弟组件的 Context。

function Parent() {
  const [state, setState] = useState(0);

  return (
    <div>
      <ChildA value={state} />
      {/* 在这里修改 state，会导致 ChildA 的 Context 被污染吗？ */}
      {/* 不会，因为 ChildA 的 Context 是独立的栈 */}
      <button onClick={() => setState(s => s + 1)}>Change</button>
    </div>
  );
}

通过理解源码，我们知道，React 内部有一道严格的“安检门”（栈检查）。无论你在外面怎么折腾，只要组件在正确的栈帧里，它就读取正确的值。

最后的建议：
写 React 代码时，尽量保持 Context 的不可变性。Provider 的值最好是一个新的对象或者引用。这样，React 在进行并发渲染时，就能通过简单的引用比较（===）来判断值是否变化，从而高效地调度渲染。

今天的源码之旅就到这里。希望大家在下次使用 useContext 时，能感觉到 React 内部那些精密的齿轮在为你转动。这不仅仅是代码，这是工程的艺术！

下课！