【图】React源码解析-从数据结构、依赖追踪机制、值传播与更新触发、以及性能陷阱与优化，深挖useContext的底层原理

createContext 与 Context 对象的数据结构

这张图展示 React 底层 Context 对象的完整结构，包括 Provider、Consumer 组件以及用于并发渲染的内部属性。

📝 源码级深度解析（数据结构） ：

1. 双值存储（_currentValue 与 _currentValue2） ：React 为了支持并发模式（Concurrent Mode） ，在 Context 对象中维护了两个当前值。_currentValue 用于同步渲染或首次挂载，_currentValue2 用于在并发渲染过程中暂存更新后的新值。这使得 React 可以在不同优先级的渲染任务之间安全切换，而不会污染主线程的 Context 值。

2. Provider 的本质：Provider 是一个普通的 React 组件（内部实现为 ContextProvider）。它接收 value prop，并在渲染时将该值写入 Context._currentValue，同时通过 Fiber 节点的 dependencies 机制通知所有订阅者。

3. Consumer 的本质：Consumer 是一个订阅者组件，它通过 useContext 或 Context.Consumer 的 render props 模式读取当前值。在 React 源码中，Consumer 会在 Fiber 协调阶段被特殊处理，建立与 Provider 的依赖关系。

4. 默认值的作用：当组件树中没有匹配的 Provider 时，useContext 会返回 createContext(defaultValue) 传入的默认值。这个默认值会被写入 _currentValue 作为初始值。

useContext 的挂载与读取流程（依赖追踪）

这张图展示函数组件调用 useContext 时，React 如何读取当前值，并将该上下文记录到 Fiber 节点的依赖列表中。

📝 源码级深度解析（依赖追踪） ：

1. 依赖列表（dependencies）的作用：每个 Fiber 节点维护一个 dependencies 链表，记录了该组件在本次渲染中读取过的所有 Context 对象。当某个 Provider 的值发生变化时，React 会遍历子树的 Fiber 节点，检查其 dependencies 列表，以决定是否需要重新渲染该组件。

2. readContext 的核心逻辑：readContext 不仅返回值，还会执行 pushContextDependency 将当前 Context 对象推入 dependencies 列表。如果依赖列表中已经存在该 Context，则不会重复添加。

3. Hook 节点的存储：useContext 的 Hook 节点（hook.memoizedState）存储的是Context 对象本身，而不是 Context 的值。这是为了在更新阶段能够快速比较开发者传入的 Context 对象是否发生了变化。

4. 重要细节：useContext 不会因为 Context 值变化而触发组件更新，而是依赖列表让 React 在 Provider 更新时能够找到该组件并强制重渲染。这是订阅-发布模式在 Fiber 架构中的具体实现。

Provider 值变化时的传播与更新触发机制

这张图展示当 Provider 的 value 变化时，React 如何沿 Fiber 树遍历，找到依赖该 Context 的组件并触发更新。

📝 源码级深度解析（传播机制） ：

1. propagateContextChange 的核心算法：这是 Context 更新传播的核心函数。它会从 Provider 所在的 Fiber 节点开始，深度优先遍历其子树，查找所有在 dependencies 列表中记录了该 Context 的组件。这是一个 O(n)  的遍历操作，n 为子树中的 Fiber 节点数量。

2. 性能考量：React 不会因为一个 Context 变化而遍历整个应用树，而是仅遍历该 Provider 的子树。如果 Provider 放在根节点（如全局主题），其子树就是整个应用，Context 变化会触发整棵树的重渲染检查。

3. Object.is 比较：Provider 使用 Object.is 比较新旧 value 值。如果引用地址未变（如使用 useMemo 或 useState 保持引用稳定），则完全跳过遍历和更新，极大提升性能。

4. bailout 优化：即使子组件订阅了 Context，如果该组件自身没有其他变化（如 props 未变且 state 未变），React 可能通过 bailout 优化跳过其子树的渲染。但该组件本身一定会重新执行 Render（因为 flags 被标记为 Update）。

5. 并发模式下的行为：在 Concurrent 模式下，Context 传播过程是可中断的。如果传播过程中插入高优任务，React 会保存当前遍历进度，先执行高优任务，再恢复 Context 传播。

useContext 的性能陷阱与优化策略

这张图展示常见的 Context 性能陷阱（内联对象导致频繁重渲染），以及如何通过 useMemo 或拆分 Context 进行优化。

📝 源码级深度解析（性能陷阱与优化） ：

1. 内联对象的致命陷阱：如果在 Provider 中直接使用对象字面量 value={{ count: 1 }}，每次父组件渲染都会创建一个新的对象。由于 Object.is 比较的是引用地址，新旧 value 永远不同，导致 propagateContextChange 每次都遍历整个子树，强制所有消费者重渲染，即使逻辑值完全未变。

2. 优化策略一：使用 useMemo 稳定化：

   • 将 value 对象用 useMemo 包裹，依赖项为真正变化的值（如 count）。

   • 当 count 不变时，useMemo 返回上次缓存的同一对象引用，Object.is 判断为相等，Provider 完全跳过更新传播。

3. 优化策略二：拆分 Context：

   • 将变化频繁的数据（如用户输入）与稳定的数据（如主题、API 配置）拆分为独立的 Context。

   • 每个组件仅订阅它真正需要的 Context，减少因无关数据变化导致的重渲染。这是 React 官方推荐的最佳实践。

4. 优化策略三：使用状态管理库：

   • 对于大型应用，Context 的传播机制（O(n) 遍历）可能成为瓶颈。此时可考虑使用 Redux、Zustand 或 Jotai 等外部状态库，它们利用细粒度的订阅（useStore）避免了遍历整棵 Fiber 树，可大幅提升性能。

5. React 19 的新变化：React 编译器（React Compiler）将自动记忆化组件的 props 和 state，未来 useMemo 等手动优化可能不再需要。但 Context 的传播机制作为 Fiber 架构的底层逻辑，仍将保持上述工作原理。

📊 四张图总结：useContext 的完整画像