其实，

React事件程序如何工作？

在 React 开发中，很多开发者遇到过这种困惑：为什么在子组件里写了e.stopPropagation父组件的点击事件还是触发了？怎么说呢，为什么在微前端架构中，多个 React 应用会互相干扰？要解决这些痛点，必须深度理解 React 的 合成事件程序还有 事件委托的底层运行方式。

一、 合成事件程序

1. 直觉锚定

想象一个国际会议，与会者说不同语言。话说回来，主办方给每人配了同声传译耳机——不管发言人说中文、英文还是日文。你听到的都是统一语言，

React 的 SynticEvent 就是这个传译程序：

• 不同语言 = 不同浏览器的原生事件对象
• 传译耳机 = SynticEvent 封装原生事件，提供统一 API
• 你听到的统一语言 = 你在 React 里拿到的事件对象 e

但 SynticEvent 不只是"翻译"——它还是事件委托机制的调度对象携带了"哪个 Fiber 应该处理这个事件"的信息。

2. 痛点背景：性能与兼容的权衡

原生 DOM 事件处理有一个性能问题：每一个 都会绑定一个监听器。在大规模应用中，每个占用内存且频繁的绑定/解绑会产生巨大开销。

React 的方法是：不在每个元素上绑定事件。而在根节点统一监听，通过冒泡分发。这就是事件委托。

3. 主要数据结构

SynticEvent 对象

// react@. · packages/react-dom/src/events/SynticEvent.js
function SynticEvent {
this.nativeEvent = nativeEvent;// 原生事件引用
this.target = nativeEvent.target;this.type = nativeEvent.type;this.bubbles = nativeEvent.bubbles;// ... 传播控制标志
this.isPropagationStopped = false;this.isDefaultPrevented = false;}

关键属性：

属性	说明
nativeEvent	原生 DOM 事件的引用
isPropagationStopped	是否调用了 stopPropagation
_reactName	React 事件名
_targetInst	事件目标对应的 Fiber 实例

事件类型映射

React 把 JSX 中的 onClickonChange 等映射到原生事件类型：

simpleEventPlugin → onClick → 原生 'click'
onChange → 原生 'change'
onSubmit → 原生 'submit'
focusEventPlugin → onFocus → 原生 'focusin'
keyboardEventPlugin → onKeyDown → 原生 'keydown'

4. 运行流程：从点击到处理

① 使用者点击 
│ 浏览器在 button 上触发原生 click 事件
│ ▼② 事件冒泡到根节点
│ ▼③ React 根节点监听器触发
│ DOMPluginEventSystem.js · dispatchEvent
│ ▼④ 根据 nativeEvent.target 找到对应 Fiber
│ getClosestInstanceFromNode
│ → 从 DOM 节点向上找。找到挂了 __reactFiber$ 的节点
│ → 返回对应 Fiber 实例
│ ▼⑤ 从 target Fiber 沿 return 链向上收集事件处理器
│ accumulateTwoPhaseListeners
│ │ 收集结果：
│ │ Fiber → 有 onClick → 收集 handleClick
│ │ Fiber → 有 onClick → 收集 parentClick
│ ▼⑥ 创建 SynticEvent，依次调用处理器
│ handleClick ← 先执行
│ parentClick ← 再执行
│ │ 如果某处理器调用了 e.stopPropagation
│ → isPropagationStopped = true → 后续不再执行

dispatchEvent 的主要伪代码

// 简化自 DOMPluginEventSystem.js
function dispatchEvent {
// ① 找 target 对应的 Fiber
var targetInst = getClosestInstanceFromNode;// ② 创建 SynticEvent
var synticEvent = createSynticEvent;其实，// ③ 收集所有 onClick 处理器
var dispatchQueue =;accumulateTwoPhaseListeners;// ④ 依次执行
for {
var listeners = dispatchQueue;for {
listeners;if return，怎么说呢，}
}
}

5. stopPropagation 的实现——和原生的区别

React 的 stopPropagation 只阻止 React 事件传播。不阻止原生事件冒泡， React 事件和原生事件是两层独立的传播机制。

二、 设计动机与权衡

为什么用 SynticEvent 而不是直接用原生事件？

1. 跨浏览器一致性解决 IE event.keyCode 与标准 event.key 的差异。
2. 事件委托性能N 个元素只需 1 个监听器。
3. 与 Fiber 集成携带 _targetInst让 React 能快速关联到组件实例。

React 17+ 移除事件池的原因

在 React 16 中，SynticEvent 被池化复用——回调执行完后属性被清空。话说回来，导致会导致经典 Bug：

function handleClick {
console.log;// ✓ 同步访问正常
setTimeout => {
console.log;其实，// ✗ null！事件已被回收
},1000);}

现代 JS 引擎 GC 足够快。池化收益不再明显，反而增加了开发者困惑。

三、 事件委托的挂载点变化（React 16 vs 17+)

1. 痛点：微前端架构的冲突

在 React 16 中，所有事件监听器挂在 document 上。如果页面上存在两个 React 应用，A 应用调用了 e.stopPropagation会导致 B 应用的点击事件被截断。说起来，这在微前端架构中是致命的。怎么说呢，

2. 主要变化

// React 16: 挂在 document
document.addEventListener;// React 17+: 挂在 root DOM container
rootContainerElement.addEventListener;

// react@. · packages/react-dom/src/events/EventListener.js
function listenToAllEvents {
// 遍历所有类型，注册到 rootContainerElement
listenToNativeEvent;// bubble
listenToNativeEvent;// capture
listenToNativeEvent;// ...
}

3. 变化后的行为

现在每个 React 应用拥有自己的 rootContainerElement。A 应用调用 stopPropagation 只在 A 内部停止传播，不会影响到 B 应用的事件监听器。按理说，

四、 React 事件的执行顺序

1. 痛点：原生事件与 React 事件混用

stopPropagation 到底拦的是哪一层？

function App {
useEffect => {
document.addEventListener => console.log);// 原生
},)，return (

console.log}> // React Bubble
 console.log} // React Bubble
ref={el => el?.addEventListener => console.log)} // 原生
>
Click


);}

2. 主要规则

原生事件沿着 DOM 树冒泡。当冒泡到 root container 时React 的 dispatchEvent 被触发，接下来执行 React 处理器。

3. 运行流程全解析

1. 使用者点击 button原生 click 事件触发。
2. target 阶段执行 button 上的原生监听器 D。
3. 冒泡到 div无原生监听器，跳过。说起来，
4. 冒泡到 root containerReact dispatchEvent 触发！
   • 找到 target对应的 Fiber，沿 return 链收集 React 处理器。
   • 依次执行的观点是，C -> B。
5. 冒泡到 body执行原生监听器 A。

最终输出：D → C → B → A

---