React 的事件机制和合成事件是如何工作的？

深入理解 React 事件机制：从事件委托到合成事件

在日常的 React 开发中，为组件绑定事件监听器几乎是我们的肌肉记忆，比如 onClick、onChange 等。我们通常只需声明一个事件处理函数，React 就能确保它在正确的时机被调用。

这种看似简单的交互背后，隐藏着一套由 React 精心设计的事件处理机制。它并没有直接使用原生的浏览器事件模型，而是构建了一个名为 合成事件（SyntheticEvent） 的抽象层。这套机制不仅解决了跨浏览器的兼容性问题，还通过事件委托等方式提升了应用的整体性能。

在这篇文章中，我们将一起深入探讨 React 的事件系统，从底层的事件委托，到核心的合成事件，彻底理解我们每天都在使用的 e.preventDefault() 究竟是如何运作的。

性能基石：事件委托（Event Delegation）

在深入 React 之前，我们先来回顾一个经典的前端性能优化技巧：事件委托。

设想一个场景：一个列表中有成百上千个条目，每个条目都需要响应点击事件。如果为每个条目都单独绑定一个事件监听器，那么 DOM 中就会存在成百上千个监听器。这不仅会增加内存开销，还可能影响页面性能。

事件委托的思路则完全不同。它利用了浏览器事件模型中的 事件冒泡（Event Bubbling）机制。具体来说，我们可以只在这些列表项的共同父元素上绑定一个监听器。当某个列表项被点击时，这个点击事件会从被点击的元素（target）开始，逐级向上冒泡，直到被父元素的监听器捕获。此时，我们可以通过事件对象（event.target）来判断事件的真正来源，并执行相应的逻辑。

React 巧妙地将这一思想应用到了整个应用层面。**在 React 17 之前，它会在 document 节点上为每种事件类型只注册一个监听器。从 React 17 开始，这个监听器则被附加到了渲染 React 应用的根节点（root）上。

这意味着，无论我们在应用的哪个组件、哪个角落绑定了多少个 onClick，最终都只有一个真正的 onClick 监听器附加在 DOM 树的顶端。当任何一个元素的事件被触发时，该事件都会冒泡到根节点，由这个唯一的监听器统一处理和分发。

这种集中式的事件管理，正是 React 高性能事件处理的基石。

核心抽象：合成事件（SyntheticEvent）

当原生事件被根节点的监听器捕获后，React 并没有直接将这个原生事件对象传递给我们的组件。相反，它将其包装成了一个 SyntheticEvent 对象。

SyntheticEvent 是 React 对原生浏览器事件的跨浏览器封装。它抹平了不同浏览器在事件对象上的实现差异，确保了 API 的一致性。例如，我们无需再纠结是使用 event.target 还是 event.srcElement，也无需关心 event.preventDefault() 的兼容性问题。在 SyntheticEvent 的世界里，我们只需要使用 W3C 标准的 API 即可。

这背后的主要动机有两个：

• 1. 跨浏览器兼容性：这是最直接的原因。不同浏览器对事件对象的实现存在诸多差异。SyntheticEvent 提供了一个统一的、符合 W3C 规范的接口，让开发者可以编写一次代码，在所有现代浏览器中都能得到一致的行为。
• 2. 性能与事件池（Event Pooling）：为了进一步提升性能，React 引入了事件池机制。当一个事件处理函数执行完毕后，SyntheticEvent 对象上的所有属性都会被清空（nullified），然后该对象会被“释放”并放回事件池中，等待下一次事件的复用。这避免了在每次事件触发时都频繁创建和销毁事件对象所带来的性能开销。

这也解释了一个常见的现象：为什么我们不能在异步回调函数中直接访问 event 对象？

function handleClick(e) {
  console.log(e.type); // "click"
  setTimeout(() => {
    console.log(e.type); // 报错或输出 null
  }, 100);
}

因为在 setTimeout 的回调执行时，handleClick 早已执行完毕，e 这个合成事件对象已经被回收并重置了。如果我们确实需要在异步操作后访问事件的属性，需要调用 e.persist() 方法，这会将该事件从池中移除，允许我们持久地保留对它的引用。

当然，如果你需要访问底层的原生事件对象，React 也提供了途径，可以通过 e.nativeEvent 属性来获取。

串联完整流程：一次点击的生命周期

现在，我们将上述两个概念串联起来，完整地看一下在 React 应用中，从用户点击到一个函数被执行的全过程：

• 1. 应用加载：React 在应用根节点上注册了各种事件（如 click, change 等）的统一监听器。
• 2. 用户交互：用户点击了应用中的一个按钮。浏览器会创建一个原生的 click 事件。
• 3. 事件冒泡：这个原生事件从被点击的按钮开始，在 DOM 树中逐级向上冒泡。
• 4. 根节点捕获：当事件冒泡到 React 的根节点时，被 React 注册的那个唯一的 click 监听器捕获。
• 5. 事件分发：React 的事件系统接管。

• 它首先根据原生事件的 target，确定事件源自 React 组件树中的哪个具体组件。

• 然后，它从事件池中取出一个 SyntheticEvent 对象，并填充上原生事件的信息，形成一个跨浏览器兼容的事件对象。

• 接着，React 模拟事件冒泡的路径，在自己的组件层级结构中，从源组件开始，向上遍历所有父组件，依次调用在 props 中定义的事件处理函数（如 onClick）。

• 6. 执行处理函数：我们编写的 onClick 方法被执行，并接收到 SyntheticEvent 对象作为参数。
• 7. 事件回收：一旦我们组件中的所有事件处理函数都执行完毕，这个 SyntheticEvent 对象就会被回收，其所有属性被清空，并放回事件池中等待下一次复用。

总结

通过对 React 事件机制的梳理，我们可以得出几个关键结论：

• 性能：React 通过在根节点进行事件委托，极大地减少了真实 DOM 上的事件监听器数量，从而优化了内存和性能。

• 兼容性：SyntheticEvent 作为核心抽象，抹平了浏览器的差异，为开发者提供了稳定、统一的事件处理接口。

• 事件池：为了避免频繁创建和销毁对象，SyntheticEvent 采用了池化技术进行复用，这也是不能在异步任务中直接访问事件对象的原因。如需持久化，应使用 e.persist()。

• 两个“冒泡”：整个过程涉及两次“冒泡”。第一次是原生事件在真实 DOM 树中的冒泡，直到被 React 根监听器捕获；第二次是 SyntheticEvent 在 React 虚拟组件树中的“模拟冒泡”，依次触发各层级组件的事件处理器。

理解了这套机制，我们不仅能写出更健壮的 React 应用，还能在遇到棘手的事件相关问题时，拥有更清晰的调试思路，从容地定位问题根源。