发布于 由admin

React 事件系统细节：源码解析 stopImmediatePropagation 在合成层级与原生层级的行为差异与隔离真相

各位好，我是你们的 React 老司机，今天咱们不聊那些花里胡哨的 Hooks，也不聊怎么用 CSS 做出那种“看起来很贵”的阴影。咱们来聊聊那个看似简单，实则暗藏杀机、足以让无数前端工程师在深夜里抓狂的——事件系统。

特别是那个大名鼎鼎、却总是让人摸不着头脑的方法：stopImmediatePropagation。

很多人以为 React 的 stopPropagation 和原生的 stopPropagation 是一回事，以为只要调用了它，世界就清净了。但真相往往比电视剧还狗血。今天，我们就把这层窗户纸捅破，看看在 React 的合成事件层和原生的 DOM 事件层之间，究竟发生了什么“谍战剧”。

准备好了吗？系好安全带，我们要进坑了。

第一部分：两个世界，两个规则

首先，咱们得搞清楚，我们面对的是什么。

原生世界（Native）：
这是一个粗犷、直接、甚至有点野蛮的世界。当你在一个 div 上监听 click 事件时，浏览器会乖乖地给你发通知。这个事件会从你点击的那个 div 开始，一层一层往上冒泡，直到 body，再到 html，最后到 document。这就是所谓的“事件冒泡”。

React 世界（Synthetic）：
这是一个精致、优雅、甚至有点洁癖的世界。React 觉得原生的 DOM 事件太乱了，不够统一。于是，它搞了一套自己的“合成事件系统”。
React 把所有的事件监听器都挂载到了 document 上（或者 window 上），这就是传说中的事件委托。当你点击一个按钮时，React 并不是直接在那个按钮上监听，而是等事件冒泡到 document，React 捡起来一看：“哦，原来是这个按钮触发的”，然后它会在自己内存里模拟一个事件对象，这就是合成事件。

核心矛盾：
现在，你手里有两个世界，一个在 div 上，一个在 document 上。当一个事件发生时，这两个世界的“保安”会怎么反应？这就引出了我们今天的男主角——stopImmediatePropagation。

第二部分：stopImmediatePropagation 是谁？

在深入代码之前，咱们得先认识一下这个“狠人”。

它的官方定义是：立即停止事件的传播，并阻止该事件在捕获或冒泡阶段的其他监听器被调用。

简单翻译一下：“别传了！而且，这一行上其他的监听器，一个都不许跑！”

它有两个作用：

  1. stopPropagation：停止事件冒泡/捕获（不告诉父元素了）。
  2. stopImmediatePropagation：阻止同目标上的其他监听器执行。

这哥们儿就像是一个恶霸，不仅把信使打晕（停止传播），还把同车厢的其他乘客都踢下车（阻止其他监听器）。

第三部分：场景一——React 中的 stopImmediatePropagation

让我们先看看在 React 里，这哥们儿有多“横”。

代码示例：

import React, { useState } from 'react';

const ReactWorld = () => {
  const [msg, setMsg] = useState('原生事件');

  // React 事件处理程序 A
  const handleReactClick = (e) => {
    console.log('🚩 React 事件 A 触发了！');
    e.stopPropagation(); // 停止冒泡
    e.stopImmediatePropagation(); // 停止传播，并阻止其他 React 监听器
  };

  // React 事件处理程序 B (在同一元素上)
  const handleReactClick2 = (e) => {
    console.log('🚫 React 事件 B 被阻止了！'); // 这行永远不会执行
  };

  // 原生事件监听器 C (在 document 上)
  React.useEffect(() => {
    const handleNativeClick = (e) => {
      console.log('🌍 原生事件 C (document) 触发了！'); // 这行会执行吗？
    };
    document.addEventListener('click', handleNativeClick);
    return () => document.removeEventListener('click', handleNativeClick);
  }, []);

  // 原生事件监听器 D (在具体的 div 上)
  React.useEffect(() => {
    const handleNativeDivClick = (e) => {
      console.log('🌍 原生事件 D (div) 触发了！'); // 这行会执行吗？
    };
    // 注意：这里直接挂载在 div 上，而不是 document
    document.getElementById('myDiv').addEventListener('click', handleNativeDivClick);
    return () => document.getElementById('myDiv').removeEventListener('click', handleNativeDivClick);
  }, []);

  return (
    <div id="myDiv" onClick={handleReactClick}>
      <button>点我</button>
      <p>状态: {msg}</p>
    </div>
  );
};

运行结果预测：
当你点击按钮时，控制台会输出什么？

  1. 🚩 React 事件 A 触发了！ (A 跑了)
  2. 🚫 React 事件 B 被阻止了！ (B 被秒杀)
  3. 🌍 原生事件 D (div) 触发了！ (D 跑了) —— 关键点！
  4. 🌍 原生事件 C (document) 触发了！ (C 没跑) —— 关键点！

真相解析：

在 React 中调用 stopImmediatePropagation，会产生一个非常有趣的“隔离效应”：

  1. 阻止同僚： 它确实阻止了同一个 React 元素上的其他 onClick 处理函数。这很符合直觉。
  2. 阻止原生监听器 (document)： React 的合成事件系统会“拦截”原生事件。当你调用 stopImmediatePropagation 时，React 会模拟停止传播，并且 React 内部逻辑通常会阻止原生事件继续冒泡到 document。所以，挂载在 document 上的原生监听器 C，不会被触发。
  3. 放过原生监听器 (div)： 这是重点！React 的合成事件目标通常是 document（因为委托），而原生事件的目标是具体的 DOM 元素（比如 div）。stopImmediatePropagation 是基于“目标”来判断的。
    • React 事件的目标是 document。
    • 原生事件 D 的目标是 div。
    • 它们不是同一个目标！
    • 所以，React 事件 A 的 stopImmediatePropagation 只能管到 document 层级，管不到 div 层级。
    • 结论： React 的 stopImmediatePropagation 不会阻止在具体元素上注册的原生监听器。它只是阻止了原生事件继续往 document 冒泡。

第四部分：场景二——原生世界中的 stopImmediatePropagation

好了，现在我们换位思考。如果你是那个在 document 上监听的原生监听器，看到 React 的合成事件在搞事情，你会怎么反击？

代码示例：

// 假设我们有一个 div，上面有一个 React 按钮
const btn = document.querySelector('button');

// 原生事件监听器 E (document)
document.addEventListener('click', (e) => {
  console.log('🌍 原生事件 E (document) 触发了！');
  e.stopPropagation(); // 停止传播
  e.stopImmediatePropagation(); // 停止传播，并阻止其他监听器
}, true); // 使用捕获阶段，为了更有趣一点

// React 事件处理程序 F (在 button 上)
// React 会在 document 上注册一个合成事件来代理这个 button

运行结果预测：
当你点击按钮时，控制台会输出什么？

  1. 🌍 原生事件 E (document) 触发了！ (E 跑了)
  2. 🚫 React 事件 F 被阻止了！ (F 没跑) —— 关键点！

真相解析：

在原生世界中调用 stopImmediatePropagation，它的威力是毁灭性的，因为它直接作用于原生事件对象：

  1. 阻止同僚： 它阻止了 document 上其他原生监听器（比如你可能会挂载的其他第三方库的监听器）。
  2. 阻止 React 事件： React 的合成事件是基于原生事件冒泡的。虽然 React 做了委托，但归根结底，React 是在监听原生事件。一旦你在原生监听器里调用了 stopImmediatePropagation，原生事件对象就不再冒泡了。
  3. 结局： React 根本就收不到这个事件通知，自然也就不会触发你的 handleReactClick。

结论： 原生的 stopImmediatePropagation 会完美阻止 React 的合成事件。

第五部分：隔离的真相——到底谁控制了谁？

现在，我们总结一下这两场对决。你会发现，React 的“隔离”并不是完全的，它更像是一个“伪隔离”。

React 的策略：
React 试图通过“劫持”原生事件，创建一个自己的沙盒。它把所有事件都扔到 document 上处理。

stopImmediatePropagation 的博弈：

  • React 攻击原生：

    • React 调用 stopImmediatePropagation -> 阻止 document 上的原生监听器。
    • React 调用 stopImmediatePropagation -> 放过 具体元素上的原生监听器（因为目标不同）。

  • 原生攻击 React：

    • 原生调用 stopImmediatePropagation -> 阻止 React 的合成事件。

这就是“隔离的真相”：

React 的合成事件系统，本质上是一个“过滤器”。
它过滤掉了大部分原生事件（通过在 document 层级拦截），只留下了它关心的那些。

但是，如果你在 React 组件外部（或者内部但通过原生方式注入）在具体元素上绑定了原生监听器，React 是管不到的。这些监听器就像是在 React 的围墙外面偷偷安了监控探头。

反之，如果你在 document 上绑定了原生监听器，并且你很霸道（调用了 stopImmediatePropagation），React 的围墙就会被你推倒，它根本进不来。

第六部分：源码级别的“脑补”解析

为了让这事儿更透彻，咱们来“脑补”一下 React 源码（简化版）大概长什么样。

React 如何处理事件冒泡：

// 伪代码
function dispatchEvent(domNode, eventType) {
  // 1. 创建合成事件对象
  const syntheticEvent = createSyntheticEvent(domNode, eventType);

  // 2. 获取该节点上所有 React 注册的监听器
  const listeners = getReactListeners(domNode);

  // 3. 遍历执行监听器
  listeners.forEach(listener => {
    // 这里的 syntheticEvent 就是传递给组件的 e
    listener(syntheticEvent);

    // 关键点来了：如果用户调用了 stopImmediatePropagation
    if (syntheticEvent.isPropagationStopped) {
      return; // 停止执行剩下的监听器
    }
  });

  // 4. 处理完 React 逻辑后，决定是否让原生事件继续冒泡
  // React 默认会阻止原生冒泡，除非你明确设置了某些属性
  if (!syntheticEvent.isPropagationStopped) {
    // 调用原生事件对象的 stopPropagation
    // 这一步决定了 document 上的原生监听器会不会被触发
    nativeEvent.stopPropagation(); 
  }
}

stopImmediatePropagation 的实现逻辑：

// 伪代码
function stopImmediatePropagation() {
  this.isPropagationStopped = true; // 停止冒泡
  this.isImmediatePropagationStopped = true; // 停止后续监听器

  // 关键：它直接修改了原生事件对象
  // 这就是为什么它能影响原生世界，也能影响 React 世界（因为 React 依赖原生对象）
  this.nativeEvent.stopImmediatePropagation(); 
}

这就是为什么 React 中调用 stopImmediatePropagation 会阻止 document 上的原生监听器：
因为 React 内部代码执行了 this.nativeEvent.stopImmediatePropagation()。

这就是为什么 React 中调用 stopImmediatePropagation 不会阻止 div 上的原生监听器：
因为 React 的合成事件目标是 document，而 div 上的监听器是“独立”的，它们不共享同一个合成事件目标。React 的逻辑只负责拦截 document 这一层。

第七部分：实战中的坑与建议

了解了这些原理，我们在写代码时就要小心了。这里有几个典型的坑：

坑 1：在 React 中使用 useEffect 直接绑定原生事件
很多新手为了省事，会在 useEffect 里直接 document.addEventListener('click', ...)。

  • 后果： 如果你在 React 组件里调用了 stopImmediatePropagation，你可能会发现 document 上的原生监听器没反应（被 React 阻止了），但你可能会忘记具体元素上可能还有原生监听器。这会导致逻辑混乱。

坑 2：同时使用 React 和原生库（如 Chart.js 或 D3.js）
这些库通常喜欢在 DOM 元素上绑定原生事件。

  • 后果： 如果你用 React 的 stopImmediatePropagation，React 事件能阻止原生库事件冒泡，但你可能不希望阻止原生库在元素本身上的回调。这时候，React 事件处理函数里的 e.stopPropagation() 可能会误伤库的逻辑。

坑 3：跨层级的冲突
假设你有一个父组件 Parent（React），里面有个 div（原生监听器），div 里面有个 button（React 监听器）。

  • 场景： 点击按钮。
  • 顺序：
    1. 原生 div 监听器触发。
    2. React button 监听器触发（它调用了 stopImmediatePropagation）。
  • 结果：
    • React button 事件阻止了冒泡。
    • React 事件阻止了 document 上的监听器。
    • 但是，原生 div 监听器已经执行了（因为它是目标元素，还没冒泡呢）。React 的 stopImmediatePropagation 管不到它。

建议：

  1. 统一战线： 尽量不要混用 React 事件和原生事件。如果必须用原生事件，最好封装一个 React Wrapper，或者明确标记出哪些是原生事件。
  2. 谨慎使用 stopImmediatePropagation： 这是个核武器。除非你 100% 确定不需要触发其他任何监听器，否则用普通的 stopPropagation 就够了。
  3. 理解目标（Target）： React 事件的目标永远是 document（或顶层容器），原生事件的目标是触发点。这是理解隔离真相的钥匙。

结语：混乱中的秩序

好了，各位老司机，今天的讲座就到这里。

我们今天像剥洋葱一样，一层层剥开了 React 事件系统的内核。我们看到了 stopImmediatePropagation 这个看似简单的 API，在 React 的合成层和原生的 DOM 层之间，竟然上演了一出“你拦不住我，我也管不着你”的精彩好戏。

总结一下核心真相：

  1. React 事件的目标是 document，原生事件的目标是元素。
  2. React 的 stopImmediatePropagation 会阻止 document 上的原生监听器，但不会阻止具体元素上的原生监听器。
  3. 原生的 stopImmediatePropagation 会直接秒杀 React 的合成事件。
  4. 所谓的“隔离”，其实是基于事件目标和冒泡路径的博弈。

希望这篇文章能让你在下次遇到事件冲突时，不再手忙脚乱。记住，代码的世界里没有绝对的隔离，只有规则和博弈。

下次见！记得，点击前先想想，你的 stopImmediatePropagation 到底想干掉谁！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注