各位同学，大家好！
欢迎来到今天的“React 内部架构深度巡礼”专场。我是你们的主讲人，一个在 React 源码里摸爬滚打多年的资深“搬砖工”。
今天我们要聊的话题，听起来有点吓人，甚至有点枯燥：React 回调函数缓存池，以及内置事件处理器在 completeWork 阶段是如何被合并到节点属性中的。
别急着划走！我知道，一听到“源码”、“completeWork”、“合并”这些词，你们的大脑可能已经开始分泌皮质醇了。但请相信我，今天的讲座，我保证不讲那些教科书式的废话，我们只聊干货，只聊那些让你在面试时能镇住场子，或者在实际开发中遇到内存泄漏时能一眼看穿病灶的“黑魔法”。
我们要解决的核心问题是：React 是如何聪明地处理那些成千上万个 onClick、onChange 的？它为什么不需要给每个按钮都挂载一个监听器？它又是怎么知道，这个函数是新的，还是旧的？
准备好了吗？让我们把 React 的内部世界像拆解一台精密的瑞士手表一样，一块块拆开来看看。
第一部分：事件委托的“独裁者”与内存的诅咒
在深入 completeWork 之前，我们必须先理解 React 事件系统的底层逻辑。这就像是一个独裁国家的治理模式。
在原生 DOM 开发中，如果你想给页面上的 100 个按钮添加点击事件，你通常会写 100 行 document.getElementById('btn1').addEventListener('click', ...)。这就像是在广场上给每个人发一张传单，效率低下，维护困难。
React 呢？React 是个独裁者。它不关心你有多少个按钮，它只关心一个容器。通常是 div#root 或者 document。
想象一下，React 在根节点上挂载了一个超级监听器。当用户点击页面任何地方时，这个监听器就会捕获到事件。然后，React 会问：“是谁点的？”
这时候，React 就需要一张“身份证”。这张身份证就是事件名（比如 click）。
但是，问题来了。
第二部分：回调函数的“幽灵”与内存泄漏的隐患
假设你写了一个简单的计数器组件：
function Counter() {
const [count, setCount] = useState(0);
return <button onClick={() => setCount(count + 1)}>Count is {count}</button>;
}每次 Counter 组件重新渲染，onClick={() => setCount(count + 1)} 这个箭头函数都会被重新创建。在 JavaScript 中，函数是对象，对象是引用。这意味着，每一次渲染，这个函数的内存地址都变了。
如果在 React 17 之前（或者某些没有优化的场景），如果 React 直接把这个函数绑定到 DOM 节点上，或者传递给事件委托系统，它每次都会认为这是一个全新的函数。这会导致什么？会导致不必要的重渲染，或者更糟糕的——旧的监听器没有被移除，内存泄漏！
React 的聪明之处在于，它不能简单地“绑定”，它必须“识别”。它需要一种机制，告诉系统：“嘿，这个 onClick 的回调函数，其实和上一次渲染的那个是同一个，别折腾了。”
这就是我们要讲的回调函数缓存池的核心思想：通过某种哈希或引用机制，缓存事件处理函数，避免重复绑定。
第三部分：completeWork —— 建筑工地的“收尾阶段”
好了，现在我们进入正题。当 React 完成了“协调阶段”的数学运算，生成了新的 Fiber 树之后，它开始进入“构建阶段”。
在构建阶段，React 会遍历 Fiber 树，根据 Fiber 节点的类型，创建真实的 DOM 节点。这个过程发生在 completeWork 函数中。
completeWork 是一个巨大的 switch 语句。它处理 HostComponent（DOM 节点）、ClassComponent、FunctionComponent 等等。
我们的目标是：在构建 DOM 节点的同时，将事件处理器合并进去。
让我先给你们看一个简化版的 completeWork 逻辑（这是 React 源码的精髓）：
// 伪代码：简化版 completeWork
function completeWork(current, workInProgress) {
const tag = workInProgress.tag;
if (tag === HostComponent) {
// 如果是 DOM 节点，开始构建
const newProps = workInProgress.pendingProps;
// 1. 创建 DOM 节点
const domNode = createDom(workInProgress);
// 2. 关键步骤：合并属性
// 这里就是我们今天要讲的重点
reconcileProps(domNode, newProps, workInProgress);
// 3. 完成工作，将 DOM 指针指回去
workInProgress.stateNode = domNode;
}
// ... 其他类型的处理
}看到 reconcileProps 了吗？这就是那个“魔法师”。它负责把 pendingProps（待处理的属性）应用到 domNode 上。
第四部分：reconcileProps 的合并艺术
在 React 内部，并没有直接调用 element.onclick = handler。那样太原始了。
React 会遍历 newProps（也就是我们的 onClick、onChange 等属性）。它会执行一个过滤逻辑。
// 伪代码：reconcileProps 中的属性合并逻辑
function reconcileProps(domNode, newProps, workInProgress) {
// React 会过滤掉一些特殊属性，比如 key, ref 等
// 然后把剩下的属性分两类：普通属性 和 事件属性
// 我们先关注事件属性
const eventProps = {};
const otherProps = {};
for (let key in newProps) {
if (key.startsWith('on')) {
// 如果是事件名，比如 onClick, onChange
eventProps[key] = newProps[key];
} else {
// 普通属性，比如 className, id
otherProps[key] = newProps[key];
}
}
// 1. 先把普通属性塞进去
for (let key in otherProps) {
domNode.setAttribute(key, otherProps[key]);
}
// 2. 再处理事件属性
// 这里的逻辑非常关键，它涉及到了“缓存池”的雏形
if (Object.keys(eventProps).length > 0) {
// 我们不直接调用 addEventListener，而是先收集起来
// 这就是所谓的“缓存池”机制：先缓存，后批量处理
mergeEvents(domNode, eventProps, workInProgress);
}
}第五部分：揭秘 mergeEvents —— 缓存池的运作机制
现在，我们来到了最精彩的部分。mergeEvents 函数是如何工作的？它如何处理那些成千上万个回调函数？
在 React 源码中，这个逻辑通常被封装在 dispatchEventsByPriority 或者类似的函数里。但为了方便理解，我们模拟一下这个流程。
React 不会在 completeWork 阶段直接把事件绑定到 DOM 上，因为那样性能不好。相反，它会维护一个事件缓存池。
这个缓存池通常挂载在 DOM 节点的一个私有属性上，比如 element._reactEvents。
// 伪代码：mergeEvents 的实现
function mergeEvents(domNode, eventProps, workInProgress) {
// 初始化缓存池（如果还没有）
if (!domNode._reactEvents) {
domNode._reactEvents = {};
}
// 遍历所有事件属性
for (let propKey in eventProps) {
const propValue = eventProps[propKey]; // 这就是那个箭头函数
// 关键点 1：缓存池检查
// React 不会每次都重新创建监听器，而是检查缓存池里有没有这个 propKey 对应的处理函数
if (domNode._reactEvents[propKey] !== propValue) {
// 如果不一样，说明这是一个新的事件处理器
// 我们需要把它存入缓存池，并注册到 DOM 上
domNode._reactEvents[propKey] = propValue;
// 这里就是“合并”的真正含义：
// React 不仅仅是在 DOM 上挂载事件，它还会把事件配置（dispatchConfig）合并进来
// 并创建一个合成事件对象
const eventType = propKey.toLowerCase().substring(2); // "onClick" -> "click"
const handler = propValue;
// 绑定事件
// 注意：React 使用的是事件委托，所以这里其实是给 DOM 节点挂载了一个统一的事件监听器
// 或者是给这个具体的 DOM 节点挂载监听器（取决于 React 版本和配置，现代 React 通常是委托）
// 但为了演示缓存池，我们假设是绑定
// 这里有一个巨大的坑：React 17+ 改变了事件系统，不再在 document 上绑定所有事件
// 而是在 rootContainer 上绑定。
// 但缓存池的逻辑依然是：记录当前节点有哪些事件监听器，避免重复绑定。
// 为了演示，我们假装这里执行了绑定：
// domNode.addEventListener(eventType, handler);
}
}
}等等，这里有个巨大的误区，我要纠正一下！
上面的代码虽然解释了“缓存”的概念，但并没有解释现代 React（React 18/19）的实际机制。现代 React 不再维护 element._reactEvents 这种映射了，因为那样太重了。
现代 React 的 completeWork 阶段，真正干的事情是：计算属性差异。
让我给你们看一段更接近真实 React 源码逻辑的 updateHostComponent 函数片段：
// React 源码中的 updateHostComponent (简化版)
function updateHostComponent(current, workInProgress, type, newProps) {
const oldProps = current.memoizedProps;
// 这里有个技巧：React 比较的是 memoizedProps (上一次渲染的) 和 pendingProps (这次渲染的)
// 如果一样，就不更新 DOM，直接复用
// 我们只关心事件属性
const hasEvent = newProps.onClick || newProps.onInput || ...;
// 这里的逻辑是：
// 1. 检查 DOM 节点是否存在
// 2. 检查属性是否变化
// 3. 如果属性变了，或者 DOM 节点还没创建，就更新 DOM
// 对于事件，React 会在一个名为 `element._reactEventListeners` 的地方做手脚
// 或者更准确地说，React 会根据 propKey 来判断是否需要更新
}真正的秘密：propKey 的唯一性
其实，所谓的“回调函数缓存池”，在 completeWork 阶段，更多的是指对 propKey 的处理。
React 不需要缓存函数对象本身（因为函数是不可变的，如果逻辑变了，函数引用自然变了）。React 需要缓存的是映射关系。
当 completeWork 遍历 workInProgress.pendingProps 时，它会生成一个 propKey。比如 onClick。
如果 React 发现，当前的 propKey 对应的 propValue 和 currentNode 上已经存在的 propKey 对应的 propValue 是同一个引用（在 React 内部，这通常通过闭包或者特殊处理来实现），那么 React 就会跳过这一步，不会重新绑定事件。
让我们看一个更硬核的代码示例，展示 completeWork 如何处理事件属性的差异：
// 假设我们在 updateHostComponent 中
function updateHostComponent(workInProgress, domNode, type, newProps) {
// 1. 普通属性合并
// React 会通过 DOM Diff 算法，只修改变化的属性
// 比如 className 变了，setAttribute('className', 'new-class')
// 2. 事件属性的特殊处理
// React 不会直接去比较函数内容，而是比较函数引用
// 为了做到这一点，React 内部维护了一个列表，记录了当前节点挂载了哪些事件
// 模拟 React 的内部逻辑：
const currentProps = workInProgress.alternate ? workInProgress.alternate.memoizedProps : null;
const prevProps = currentProps || {};
// 遍历所有事件类型
['onClick', 'onChange', 'onFocus', 'onBlur'].forEach(eventName => {
const nextProps = newProps[eventName];
const prevPropsValue = prevProps[eventName];
// 核心判断逻辑：如果事件处理器变了，或者是第一次渲染
if (nextProps !== prevPropsValue) {
// 这是一个“脏”事件，需要更新
// 步骤 A：移除旧的（如果存在）
if (prevPropsValue) {
// 这里会调用 removeEventListener
// 注意：React 17+ 使用的是统一的合成事件系统，这里会有更复杂的逻辑
// 但本质上，它是会移除的
}
// 步骤 B：注册新的
if (nextProps) {
// 这里会调用 addEventListener
// React 会把合成事件配置合并到这个函数上
domNode.addEventListener(eventName.slice(2).toLowerCase(), nextProps);
}
}
});
}第六部分：深入合成事件与“冒泡”的谎言
很多同学以为 React 的事件是绑在具体元素上的，然后冒泡到 document。
错！大错特错！
React 的 completeWork 阶段，虽然是在操作具体的 DOM 节点，但 React 18+ 引入了一种叫做 “事件委托”的升级版。
React 不会给每个按钮挂载 onclick。它会给根容器挂载。
那么，completeWork 阶段到底做了什么？
它做的不是“绑定”动作，而是“注册”动作。
在 completeWork 阶段，React 会检查当前 Fiber 节点是否需要监听事件。如果需要，它会将这个事件处理器（以及相关的合成事件配置 dispatchConfig）存储在 Fiber 节点的一个特殊属性中，比如 workInProgress.memoizedProps 或者是 Fiber 自身的 eventHandlers 数组里。
然后，当 React 到达根节点时，它会扫描整个 Fiber 树，收集所有的 eventHandlers。
这就形成了“缓存池”！
// 这是一个极其简化的概念图，展示了 completeWork 阶段如何构建这个池子
// 1. 在 completeWork 处理 Button Fiber 时
function completeWork(ButtonFiber) {
const props = ButtonFiber.pendingProps;
if (props.onClick) {
// 我们把事件处理器收集起来，存入 Fiber 节点的一个临时列表
// 这个列表就是“缓存池”的雏形
if (!ButtonFiber._eventHandlers) ButtonFiber._eventHandlers = [];
ButtonFiber._eventHandlers.push({
type: 'click',
listener: props.onClick,
// 还可以带上合成事件的配置信息
config: getSyntheticEventConfig('click')
});
}
}
// 2. 在处理完所有子节点后，回到 Root Fiber
function completeWork(RootFiber) {
// 此时，RootFiber 已经有了所有子节点的 _eventHandlers
// 它会把这些 handlers 合并起来
// 然后在 Root DOM 节点上，注册一个唯一的全局监听器
const allHandlers = collectAllHandlers(RootFiber);
// allHandlers 可能长这样：
// [
// { type: 'click', listener: () => {}, target: 'button-1' },
// { type: 'click', listener: () => {}, target: 'button-2' },
// { type: 'submit', listener: () => {}, target: 'form' }
// ]
// 在全局监听器里，通过 event.target 找到对应的 Fiber 节点
// 然后调用对应的 listener
}第七部分：实战演练——追踪一个 onClick 的生命周期
为了彻底搞懂，我们来手写一个模拟场景。
场景：
function App() {
return (
<div id="root">
<button onClick={() => console.log("Hello")}>Click Me</button>
</div>
);
}阶段一：completeWork 开始
React 创建了一个 WorkInProgress 树。
completeWork(div#root)：创建div节点，遍历pendingProps。没有事件属性。completeWork(button)：创建button节点，遍历pendingProps。- 发现
onClick。 - 缓存池操作：React 检查
button节点是否已经有_reactEvents。没有。 - 创建
_reactEvents对象。 button._reactEvents.onClick = () => console.log("Hello")。- 关键动作：调用
button.addEventListener('click', () => ...)。注意，这里注册的函数，React 会做一层包装，变成一个合成事件处理器。
- 发现
阶段二：提交阶段
React 将 button 插入到 DOM 树中。
此时，浏览器中确实有一个 onclick 监听器在 button 上（通过 addEventListener）。
阶段三：第二次渲染
用户点击了按钮，触发了状态更新，React 开始第二次协调。
- React 再次调用
completeWork(button)。 - 它再次读取
pendingProps。 - 它读取
memoizedProps（上一次的）。 - 比对：
pendingProps.onClick是一个新的箭头函数。memoizedProps.onClick是旧的箭头函数。 - 结果：不一样！
- 缓存池更新：
- React 发现
button._reactEvents.onClick里的函数引用和新的不一样。 - 它执行
button.removeEventListener('click', 旧的函数)。 - 它执行
button._reactEvents.onClick = 新的函数。 - 它执行
button.addEventListener('click', 新的函数)。
- React 发现
这就是所谓的“回调函数缓存池”在 completeWork 中的工作流程。它确保了 DOM 属性中的事件处理器始终是 Fiber 树当前状态所期望的那个。
第八部分：为什么这很重要？（性能与 Bug）
理解这个机制，能帮你解决什么问题？
- 避免闭包陷阱：如果你在
onClick中引用了组件的state，但 React 没有正确地更新memoizedProps，你可能会在事件触发时拿到旧的状态。这是 React 开发中经典的 Bug。 - 内存优化：通过
completeWork阶段的比对，React 避免了在每次渲染都调用addEventListener。虽然现代浏览器对重复绑定某些事件有优化，但在高频事件（如scroll）上，这能节省巨大的 CPU 开销。 - 理解事件冒泡的停止：当你调用
e.stopPropagation()时，React 的合成事件系统是如何拦截这个调用的？因为 React 在completeWork阶段注册的监听器，内部会检查e._reactName，如果发现是stopPropagation，它就不会让事件继续向父级传播。
第九部分：总结与升华
好了，同学们，今天的讲座接近尾声。让我们回顾一下我们刚才走过的“迷宫”。
React 的 completeWork 阶段，就像是装修房子的最后一步。水电煤（数据逻辑）都已经通了，现在我们要开始粉刷墙壁（DOM 渲染）。
在这个过程中，那些看似普通的 onClick、onChange，其实都是精兵强将。React 并没有让它们直接跳到墙上（DOM），而是先在脑子里（completeWork）把它们排好队，放进一个叫“事件处理器缓存池”的仓库里。
在这个仓库里，React 仔细比对：“这个函数是新的吗？”、““这个事件是不是已经绑定了？”**。如果回答是“否”，那么 React 就会执行“解绑-更新-绑定”的三部曲。
这就是为什么 React 的应用可以处理成千上万个组件而依然保持流畅的秘密。它通过 completeWork 阶段的精细化管理，实现了事件处理器的“按需合并”和“高效复用”。
所以，下次当你看到代码里写了一堆 onClick={() => {}} 时，不要只觉得它是个简单的回调。你要看到背后那个庞大而精密的 completeWork 机器，正在默默地为每一个点击事件分配它唯一的“身份证”，并将它们妥善地安置在 DOM 节点的属性之中。
这就是 React 的工程美学，也是我们作为开发者，应该去探索和尊重的技术深度。
下课！记得多看源码，少写死循环！