3. React合成事件（SyntheticEvent）：设计动机、事件池机制、与原生事件的关系

React的合成事件，说白了就是自己造了一套事件系统。我刚接触那会儿也觉得奇怪——浏览器已经有事件了，干嘛还要再包一层？后来在项目中踩过几次坑，才明白这背后的设计有多巧妙。

3.1 设计动机：为什么React要自己搞一套？

你想想看，如果每个组件都直接绑定原生事件，会有什么问题？

• 跨浏览器兼容：不同浏览器的事件对象、属性名、默认行为都不一样。React帮你抹平了差异。
• 内存管理：大量DOM事件监听器会占用内存。React用事件委托，只在根节点挂一个监听器。
• 与虚拟DOM协调：React需要知道事件何时触发、何时更新状态。原生事件没法直接和虚拟DOM的diff流程配合。

我在一个老项目中见过有人直接在componentDidMount里用addEventListener绑定事件，结果组件卸载时忘了清理，内存泄漏查了两天。嗯，从那以后我再也不敢绕过合成事件了。

3.2 事件池机制：一个容易被忽略的陷阱

React的合成事件对象是会被复用的。什么意思？看个例子：

function handleClick(event) {
  // 这里能拿到 event
  console.log(event.type); // 'click'

  setTimeout(() => {
    // 这里 event 已经被回收了！
    console.log(event.type); // null
  }, 100);
}

为什么会这样？因为React维护了一个事件对象池。事件触发后，React从池子里取出一个对象，填充属性，用完再放回去。这样做是为了减少垃圾回收的压力。

特性	合成事件（有池）	原生事件（无池）
对象复用	是，事件处理完后清空属性	否，每次触发新建对象
异步访问	需要调用 event.persist()	直接可用
内存开销	低（对象池复用）	高（频繁创建销毁）
跨浏览器	统一封装	需手动兼容

我曾经在表单提交时用setTimeout延迟打印表单数据，结果打印出来全是null。查了半天才发现是事件池搞的鬼。后来我养成了一个习惯：只要事件处理函数里有异步操作，第一行就写event.persist()。

3.3 与原生事件的关系：共存还是冲突？

合成事件和原生事件是两套独立的系统，但它们可以共存。不过要注意执行顺序。

看这个例子：

// 原生事件绑定
document.getElementById('btn').addEventListener('click', () => {
  console.log('原生事件');
});

// React 合成事件
function App() {
  return <button id="btn" onClick={() => console.log('合成事件')}>点我</button>;
}

执行顺序是：原生事件先触发，合成事件后触发。因为React的事件委托挂载在根节点上，事件从目标元素冒泡到根节点时，React才处理。

3.4 核心流程：一张图看懂

下面这张图展示了从用户点击到React状态更新的完整链路：

3.5 实际项目中的选择建议

我个人在项目中遵循这几个原则：

1. 能用合成事件就别碰原生事件。React帮你处理了兼容性和内存管理，没必要自己造轮子。
2. 需要阻止冒泡时，用 event.stopPropagation()。但要注意，它只能阻止合成事件的冒泡，拦不住原生事件。
3. 第三方库（如D3、Leaflet）需要原生事件，那就用 ref 绑定，但记得在卸载时清理。
4. 性能敏感场景：如果某个事件触发极其频繁（比如 mousemove），可以考虑用原生事件 + 节流，绕过合成事件的开销。