拆解 React 的“特工网络”：事件插件系统深度剖析

各位老铁，各位代码工匠，欢迎来到 React 事件系统的“地下世界”。

如果你觉得 React 的 onClick、onInput 只是简单的函数调用，那你可能低估了这背后的工程学奇迹。想象一下，浏览器就像一个混乱的派对现场，原生事件是那些喝醉了的客人（有的乱跑，有的叫得不一样），而 React 是那个手里拿着对讲机的安保队长。React 没法直接控制客人，它得用一套精密的插件系统和分发机制，把这些混乱的信号变成我们代码里优雅的 handleClick。

今天，我们就来扒开 React 的裤衩（开玩笑的），看看它是怎么把一个原生的 DOM 事件，变成一个被 React 统治的“合成事件”，又是怎么通过不同的 Plugin 处理器，精准地送到你组件的门口的。

准备好了吗？让我们开始这场代码的侦探之旅。

---

第一幕：混乱的派对与合成的面具

在 React 出现之前，处理跨浏览器事件简直是噩梦。

你在 IE6 上写 onclick，和你在 Chrome 上写 onclick，那感觉就像是在跟不同的物种交流。IE6 那个老古董，事件对象是个全局变量，而且它把 focus 和 blur 这类“不可冒泡”的事件强行变成了冒泡事件。而 Firefox 呢，它对某些键盘事件的处理又很独特。

React 的首席架构师们（也就是 Dan Abramov 和他的战友们）决定：我们要造一个“瑞士军刀”。

这个瑞士军刀就是 合成事件系统。

当你在 React 里写 onInput 时，React 并没有直接把浏览器的原生事件扔给你。它先在顶层拦截，然后根据你的组件结构，创建了一个合成事件。这个合成事件长得像原生事件，但行为被统一了。不管你在 Chrome 还是 Safari，e.target 都是一致的，e.preventDefault() 都能正常工作。

但这还不够。React 怎么知道一个 click 事件应该怎么处理？怎么知道一个 input 事件应该怎么处理？怎么知道一个 focus 事件应该怎么处理？

答案是：插件。

React 的事件系统并不是一个硬编码的机器，而是一个插件化的框架。它有一堆插件，每个插件负责一种或一类事件。

---

第二幕：插件架构——事件界的乐高积木

React 的事件插件注册在 EventPluginRegistry 中。这里面的插件就像是乐高积木，它们定义了规则。

一个标准的插件接口大概长这样：

const MyEventPlugin = {
  // 1. 定义这个插件能处理什么“顶层类型”的事件
  // 比如 'topClick', 'topInput', 'topFocus'
  eventTypes: {
    onMyCustomEvent: {
      phasedRegistrationNames: {
        bubbled: 'onMyCustomEvent', // 冒泡阶段
        captured: 'onCaptureMyCustomEvent', // 捕获阶段
      },
      // 依赖哪些原生事件来触发这个合成事件？
      // 比如 'topClick' 触发 'onMyCustomEvent'
      dependencies: ['topClick'], 
    },
  },

  // 2. 提取事件：这是核心魔法
  // 当浏览器冒泡上来一个 'topClick' 时，这个函数会被调用
  extractEvents: function(
    topLevelType, // 比如 'topClick'
    targetInst, // React 内部维护的 Fiber 节点
    nativeEvent, // 原生浏览器事件对象
    nativeEventTarget // 原生 DOM 节点
  ) {
    // 这里负责创建 SyntheticEvent
    // 把原生事件包装一下，塞进去
    return SyntheticMyEvent.pooledCreate(
      dispatchConfig,
      dispatchInst,
      nativeEvent,
      nativeEventTarget
    );
  },
};

React 内置了几个大名鼎鼎的插件：

1. SimpleEventPlugin（简单事件插件）： 处理 click、mouse、keyboard、focus、blur。这是最常用的家伙。
2. ChangeEventPlugin（变更事件插件）： 处理 input、change、submit。这个插件比较复杂，因为它要区分“值改变”和“失去焦点”。
3. EnterLeaveEventPlugin（进出事件插件）： 处理 mouseover、mouseout、mouseenter、mouseleave。React 把 mouseenter 和 mouseleave 纳入了冒泡流，因为原生 DOM 里这两个事件是不冒泡的。
4. UIEventPlugin： 处理滚动、缩放等 UI 变化。
5. SelectionEventPlugin： 处理选区变化。

这些插件并不是随便堆在一起的。它们有一个注册表。当你调用 ReactMount 挂载组件时，React 会遍历这些插件，把它们的 eventTypes 注册到全局配置里。

重点来了： 当你在组件里写 <input onChange={...} /> 时，React 并不是直接把 onChange 绑定到 DOM 上。React 会去 EventPluginRegistry 里找哪个插件负责处理 onChange。

---

第三幕：分发引擎——从顶层到底层的递归

好了，现在浏览器里发生了一个点击。鼠标左键按下，松开。

阶段一：捕获

React 的监听器是绑定在顶层容器（比如 div#root）上的，而不是每个按钮上。这就是事件委托。

当事件发生时，React 会先进入捕获阶段。

1. 事件触发： 浏览器在原生 DOM 上触发 click。
2. 顶层拦截： React 监听器捕获到这个 click。
3. 插件介入： SimpleEventPlugin 的 extractEvents 被调用。它发现这是个 topClick，于是它创建了一个 SyntheticEvent 对象，并把它塞进一个分发队列。
4. 配置查找： React 查找 DispatchConfig。它知道 topClick 对应 SimpleEventPlugin 的 onMouseUp 和 onClick。
5. 听众列表： React 检查你的组件树，看看哪些组件注册了 onClick（捕获阶段）。
6. 递归分发： React 从根节点开始，沿着 DOM 树向下遍历。每到一个节点，它就检查这个节点是否有 onCaptureClick。如果有，它就把这个函数加入执行列表。

阶段二：目标

当递归到达了事件发生的那个真实 DOM 节点（比如 <button>）时，就到了目标阶段。

这时候，React 会再次检查这个节点。如果它注册了 onClick（注意：这里没有 Capture 后缀），它也会被加入执行列表。

阶段三：冒泡

然后，React 开始冒泡。它沿着 DOM 树向上走，检查父组件是否有 onClick。父组件有，加进去；爷爷组件有，也加进去。

这时候，一个函数执行列表就形成了。这个列表大概是这样的：

// 伪代码示意
const executionQueue = [
  { fn: ParentComponent.handleCaptureClick, inst: Parent },
  { fn: ChildComponent.handleCaptureClick, inst: Child },
  { fn: TargetButton.handleTargetClick, inst: Target }, // 目标阶段
  { fn: GrandParentComponent.handleClick, inst: GrandParent },
  { fn: ParentComponent.handleClick, inst: Parent },
  { fn: ChildComponent.handleClick, inst: Child },
];

这就是分发。分发不仅仅是找到事件，而是要把这个事件按照正确的顺序（捕获 -> 目标 -> 冒泡）分发给正确的听众。

---

第四幕：Input 事件插件——那个最麻烦的“变色龙”

说到事件，input 事件绝对是 React 里的“高岭之花”。为什么？因为它不仅是个事件，它还涉及到数据的双向绑定。

让我们深入看看 ChangeEventPlugin。

Input vs Change：这对冤家

在 HTML 原生世界里，input 和 change 的区别非常微妙：

• input 事件： 只要输入框的值发生任何变化，就会触发。打字、粘贴、删除，瞬间触发。它是实时的。
• change 事件： 只有当输入框失去焦点（blur），或者按下了回车键时，才会触发。它代表“值的最终确认”。

React 非常聪明。在旧版本中，React 并没有直接暴露 input 事件。如果你想在输入时监听，你得用 onChange。但是 React 会根据输入框的类型和操作方式，决定何时真正触发 onChange。

这背后的逻辑就在 ChangeEventPlugin 里。

// ChangeEventPlugin 的核心逻辑（伪代码简化版）
const isInputEvent = (nativeEvent) => {
  return nativeEvent.type === 'input';
};

const shouldProcessEvent = (domEventName, nativeEvent) => {
  // 如果是 input 事件，直接处理
  if (domEventName === 'topInput') {
    return true;
  }

  // 如果是 change 事件，稍微复杂点
  if (domEventName === 'topChange') {
    // 检查这个 change 事件是否是因为焦点丢失触发的
    // 只有焦点丢失时，才认为是真正的 "change"
    return nativeEvent && nativeEvent.type === 'blur';
  }

  return false;
};

// extractEvents 函数
const extractEvents = (topLevelType, targetInst, nativeEvent, nativeEventTarget) => {
  // 1. 如果是 input 事件
  if (topLevelType === 'topInput') {
    // 创建 SyntheticEvent
    // 这个事件会暴露给 React 组件的 onInput
    return SyntheticInputEvent.pooledCreate(...);
  }

  // 2. 如果是 change 事件
  if (topLevelType === 'topChange') {
    // 只有当它是通过 blur 触发时，才创建 SyntheticChangeEvent
    // 这样组件里的 onChange 才能正确工作
    return SyntheticChangeEvent.pooledCreate(...);
  }
};

那个著名的 getNativeEvent

在 React 中，你经常会看到一个属性 event.nativeEvent。这是干什么用的？

因为 React 的合成事件是“轻量级”的。有时候，你需要知道原生事件的一些详细信息，比如 inputType（是粘贴？删除？还是拼写更正？）或者 selectionStart。

// React 组件中
function MyInput() {
  const handleChange = (e) => {
    console.log(e.target.value);
    // 注意这里，我们要用 nativeEvent
    console.log(e.nativeEvent.inputType); 
    // 'insertText', 'deleteContentBackward', 'historyUndo' 等等
  };

  return <input onChange={handleChange} />;
}

ChangeEventPlugin 在创建 SyntheticEvent 时，会把 nativeEvent 的引用保存下来。当你访问 event.nativeEvent 时，React 实际上是把那个原生事件对象借给你用一下。但这有个坑：如果你在事件处理函数里异步访问 nativeEvent，它可能会被覆盖或清理。

两个事件插件的协作

在 React 18 之前，React 的事件系统有点分裂。SimpleEventPlugin 负责冒泡的事件，而 ChangeEventPlugin 专注于表单变更。

但为了处理 beforeinput（这是一个非常新的 API，用于更精细地控制输入），React 后来引入了更复杂的逻辑。

现在的逻辑大概是：

1. 浏览器触发 topBeforeInput。
2. ChangeEventPlugin（或者更专门的 InputEventPlugin）拦截它。
3. 它创建一个 SyntheticEvent，并赋予它 type 为 beforeInput。
4. 这个事件被分发到所有注册了 onBeforeInput 的组件。

---

第五幕：执行与清理——内存管理大师

分发只是把任务扔进队列，真正的干活在执行。

执行 Dispatch

React 有一个核心函数叫 executeDispatch。它就像是一个尽职的邮递员，负责把事件交给组件。

function executeDispatch(event, listener, domEventTarget) {
  // 1. 检查是否被阻止冒泡
  // 如果组件里调用了 event.stopPropagation()，React 会在这里停止递归
  if (event.isPropagationStopped()) {
    return;
  }

  // 2. 执行回调
  // 这就是为什么你可以在 React 里直接写函数引用，不需要 bind(this)
  listener(event);

  // 3. 检查是否被阻止默认行为
  // 如果调用了 event.preventDefault()，React 会阻止浏览器的默认行为
  // 比如 form 提交，或者 a 标签跳转
}

这个函数会被递归调用。如果组件里写了 event.stopPropagation()，React 会在下一次递归调用前检查这个标志位，然后直接返回，不再往下找父组件。

重置与内存回收

这是 React 事件系统最优雅的设计之一：事件池。

你有没有想过，为什么 SyntheticEvent 里面没有 constructor？为什么你不能直接 new 一个 SyntheticEvent？

因为 React 为了性能，复用了事件对象。

想象一下，你在一个巨大的表单里，每秒钟有 100 个输入事件。如果每次都创建一个新的对象，GC（垃圾回收器）就要累死。React 只创建一个 SyntheticEvent 池子。

当事件被分发并执行后，React 会调用 event.reset()（或者类似的清理函数）。这个函数会把 event 里的属性（如 target、currentTarget、nativeEvent 等）全部设为 null 或重置为初始状态。

// SyntheticEvent 的 reset 方法（简化）
reset: function() {
  this.dispatchConfig = null;
  this._targetInst = null;
  this.nativeEvent = null;
  this.isDefaultPrevented = false;
  this.isPropagationStopped = false;
  // ... 重置其他属性
}

这样，下次有新事件进来时，React 就可以直接复用这个对象，填入新数据。

注意： 这也解释了为什么你不能在事件处理函数中保存 event 对象的引用，然后异步使用它。因为那个对象很快就会被重置成空壳。

---

第六幕：Pointer Events——现代浏览器的宠儿

随着鼠标、触摸屏、手写笔的普及，仅仅区分 click（鼠标左键）已经不够了。于是，Pointer Events API 诞生了。

React 也有专门的插件来处理这个。

topPointerDown、topPointerMove、topPointerUp。

React 的 SimpleEventPlugin 会把这些 Pointer 事件映射到合成事件中。

关键在于，SyntheticEvent 中的 pointerType 属性。

function handlePointerMove(e) {
  if (e.pointerType === 'mouse') {
    console.log("我在用鼠标划拉");
  } else if (e.pointerType === 'pen') {
    console.log("我在用Apple Pencil画画");
  } else if (e.pointerType === 'touch') {
    console.log("我在用手指戳");
  }
}

React 的插件系统在这里展示了极强的扩展性。它不需要重写整个事件分发引擎，只需要注册一个新的插件，定义 eventTypes，然后告诉分发引擎：“嘿，当 topPointerMove 发生时，创建一个 SyntheticPointerEvent，并把它分发出去。”

---

第七幕：事件委托的幕后——ReactEventListener

最后，我们得谈谈那个躲在幕后的“大管家”：ReactEventListener。

这是 React 内部的一个模块，它负责跟浏览器打交道。

1. 注册： 当你调用 ReactDOM.render 时，ReactEventListener 会遍历你组件树的根节点，给根节点的 document 或者 window 添加 addEventListener。

   • 它添加的是 topClick，而不是 click。
   • 它添加的是 topInput，而不是 input。

2. 监听： 浏览器不知道 topClick 是什么。ReactEventListener 会把这些顶层类型映射到浏览器的原生事件名：

   • topClick -> click
   • topInput -> input
   • topFocus -> focus (IE6 除外，它会映射到 focusin)

3. 分发： 当原生事件触发时，ReactEventListener 拦截它。它根据 event.target 找到对应的 React Fiber 节点。然后，它调用 EventPluginHub（分发中心），把事件分发下去。

这个架构非常解耦。浏览器层、插件层、分发层、组件层，各司其职。

---

总结：为什么我们需要这个复杂的系统？

你可能会问：“老大，写个 onClick 为什么要搞这么复杂？直接 document.onclick = ... 不香吗？”

确实，如果你只是写个简单的脚本，直接绑事件确实简单。但在构建 React 这样的大型框架时，这种复杂性是必须的：

1. 跨浏览器一致性： 没有这个系统，你写一个 click，在 Safari 上能跑，在 IE 上就炸了。
2. 性能： 事件委托避免了给成千上万个 DOM 节点绑定监听器。只有顶层容器在听。
3. 内存管理： 事件池技术大大减少了垃圾回收的压力。
4. 扩展性： 当浏览器引入了新的事件（如 Pointer Events）或新特性（如 Composition Events），React 只需要添加一个插件，就能无缝集成，而不需要重写核心逻辑。

所以，当你下次在 React 代码里敲下 <input onChange={...} /> 时，请务必心怀敬畏。你正在指挥一个庞大的、经过精密调度的特工网络，将浏览器原始的、混乱的信号，转化为你组件中优雅、可控的数据流。

代码之美，往往就藏在这些看不见的架构之中。这就是 React 事件插件系统的魅力。