React事件池

React 的事件池（Event Pooling），是 React 在早期版本（React 17 之前）中对事件系统的一种优化机制，用于提高性能、减少内存占用。但从 React 17 开始已经废弃了事件池机制。如果使用的是 React 17+，可以直接跳过事件池相关的处理逻辑。

一、什么是事件池（Event Pooling）？

在早期版本中（< React 17），React 的事件系统使用了事件对象复用机制。当在事件处理函数中访问 event 参数时，这个对象来自一个“池子”，事件结束后会被清空并返回池中复用。

function handleClick(e) {
  console.log(e.type);      // 例如：click
  setTimeout(() => {
    console.log(e.type);    // ⚠️ 此时可能是 null 或 undefined（因为事件被清空）
  }, 100);
}

为什么要用事件池？

• 减少频繁创建和销毁事件对象的内存开销；
• 提高性能。

二、事件池的副作用

因为事件对象会被复用并清空属性，所以在异步回调中再访问事件对象，就会报错或得到 null。

如何解决？

在旧版本中，若要延迟访问事件对象，需要手动调用：

e.persist();

function handleClick(e) {
  e.persist(); // 不再回收这个事件对象
  setTimeout(() => {
    console.log(e.type); // 正常访问
  }, 100);
}

三、React 17+ 之后的变化

从 React 17 开始，React 使用了更贴近浏览器的事件系统，并完全移除了事件池（event pooling）机制：

• 不再复用事件对象；
• 不需要 e.persist()；
• 异步中访问事件对象是安全的。

function handleClick(e) {
  setTimeout(() => {
    console.log(e.type); // 安全访问
  }, 100);
}

React 18（从 React 17 起）废弃事件池（Event Pooling）机制的原因，主要是出于 可维护性 和 开发者体验（DX） 的考虑，而不是性能瓶颈。以下是详细原因：

四、为什么 React 不再使用事件池（Event Pooling）

1. 现代 JavaScript 性能优化已经足够好

创建 JS 对象的开销已经很小，不再是瓶颈

• 在 React 15、16 时代，事件池是一种减少 GC 压力的性能优化；
• 但现代 JS 引擎（如 V8）对对象的内存管理已经很高效，频繁分配小对象（如事件对象）不会导致严重性能问题；
• 所以这种“优化”变得得不偿失。

2. 事件池让事件处理变得“不直观”

事件对象在异步中变为空，让人困惑、难以 debug。

• 事件对象属性会在事件处理后立即被清空；
• 所以写出以下代码时：

function handleClick(e) {
  setTimeout(() => {
    console.log(e.type); // ❌ React 16 中为 null，会让初学者迷惑
  }, 0);
}

• 很多人会不理解为什么 e.type 是 null，必须调用 e.persist() 才行，这很反直觉，也增加了学习成本。

3. 支持并发模式需要更灵活的事件系统

事件池在并发渲染/异步事件场景下变成了阻碍

React 17+ 开始为 并发模式（Concurrent Mode） 做铺垫：

• 并发渲染涉及多个渲染阶段和异步处理；
• 如果事件对象复用、状态变化不一致，可能导致难以维护的 Bug；
• 所以新事件系统选择了 直接模拟浏览器原生事件机制，每个事件对象都单独生成、独立存在，避免共享状态。

4. 移除事件池简化了代码和维护

更简单、更直观、更接近 DOM 原生行为。

• 避免维护一套自定义对象池逻辑；
• 避免 SyntheticEvent 的复杂生命周期管理；
• 更容易与原生 DOM、第三方库兼容。

五、总结

React 版本	是否使用事件池	是否需要 e.persist()
< 17	✅ 是	✅ 需要
>= 17	❌ 否	❌ 不需要