发布于 由admin

React 源码细节：深度解析 stopPropagation 在 React 合成层级与原生浏览器 DOM 层级实现的逻辑隔离及其潜在陷阱

各位老铁，大家好，欢迎来到今天的深度技术讲座。我是你们的老朋友，专门在代码堆里打滚、在浏览器底层“钓鱼”的资深专家。

今天我们要聊的话题，非常劲爆，非常刺激，甚至有点让人后背发凉。它关乎我们每天在 React 里写的那几行 onClick、onMouseEnter，关乎那个看似简单的 stopPropagation。很多人以为它就是原生的 e.stopPropagation()，简单粗暴，一招鲜吃遍天。错！大错特错！

我们要深入 React 的“万花筒”里，去看看在这个合成事件系统下，stopPropagation 是如何在这个层层叠叠的逻辑迷宫里玩捉迷藏的。

准备好了吗？我们要开始“挖坑”了。

第一部分：原生 DOM 的野蛮时代

在 React 出现之前，或者说在 React 出现但我们还直接用 document.createDocumentFragment 的时代，浏览器里的世界是野蛮生长的。我们直接监听原生事件，逻辑简单直接。

想象一下，你在一个大池塘里扔了一块石头。

<!-- Native DOM -->
<div onclick="handleDivClick(event)">
  <button onclick="handleButtonClick(event)">点我</button>
</div>

当你在按钮上点一下，原生事件会经历这么一个过程：

  1. 捕获阶段：事件像从天而降的陨石，穿过按钮，穿过 div，穿过 document。
  2. 目标阶段：陨石砸中了按钮。
  3. 冒泡阶段：按钮“噗”的一声，把消息传给了 div，div 再传给 document。

如果你在按钮的点击处理函数里写：

function handleButtonClick(e) {
  console.log('按钮被点了');
  e.stopPropagation(); // 停止冒泡
  setTimeout(() => {
    console.log('这行代码执行时，事件已经停止了');
  }, 0);
}

这非常完美。e.stopPropagation() 是告诉浏览器：“别把我的动静传给上面了，我在自己的地盘混，不想让上面的人知道。” 浏览器乖乖听话，事件在按钮这里戛然而止。

这就是原生 DOM 的逻辑，简单、粗暴、线性。

第二部分：React 的“虚伪”伪装

但是，React 出现了。它不想让我们直接跟那个杂乱无章、不同浏览器行为各异的原生 DOM 对话。React 嫌弃浏览器太吵，于是它决定“骗”我们。

React 给我们提供了一个 SyntheticEvent（合成事件）。这就像是给浏览器装了个翻译官。

// React
function App() {
  return (
    <div onClick={handleDivClick}>
      <button onClick={handleButtonClick}>点我</button>
    </div>
  );
}

在 React 的世界里，事件是“捕获”的。注意，不是冒泡。React 的设计者为了统一跨浏览器的行为，强制把事件变成了捕获模式。这意味着，事件会先经过 div，再经过 button。

当我们调用 e.stopPropagation() 时，React 做了什么？

它并没有停止原生事件的冒泡！

这是最大的坑。

React 为了性能，为了统一，搞了一个“事件池”。它会在内存里预创建一堆合成事件对象，用完一个，复用另一个。这就像是那个借书不还的图书馆，你刚看完一本书，故事还在脑子里，但书已经被收回去了。

React 内部维护了一个巨大的 dispatchQueue。当你在组件里调用 stopPropagation 时，React 只是往这个队列里塞了一个标记。它会拦截 React 层面的后续处理程序的执行，但是，那个底层的、原生的事件对象（React 用的那个）还在继续向上冒泡。

你可能会问：“既然它还在冒泡，那我外层的 div 的 onClick 怎么没触发？”

因为 React 拦截了！它把那一层给“封”住了。

第三部分：源码深扒——那个看不见的“flag”

好，我们打开源码，看看这个 stopPropagation 到底是怎么运作的。别担心，我不带你们走那些晦涩的编译流程，我们只看运行时逻辑。

核心文件通常在 packages/react-dom/src/events/ReactDOMEventListener.js 附近。

1. 事件监听的挂载

当组件渲染时，React 会在根节点上挂载事件监听器。

// 简化的伪代码逻辑
function mountRootContainer(container) {
  const reactRoot = new ReactRoot(container);
  reactRoot.render(<App />);

  // 关键点：React 拦截了顶层事件
  const nativeEventListener = window.addEventListener; // 备份原生方法
  window.addEventListener = function(eventType, listener, ...args) {
    // 如果是我们要监听的事件，我们自己写逻辑
    if (isReactEventType(eventType)) {
      return reactEventListener.listen(eventType, listener, ...args);
    }
    // 否则用原生的
    return nativeEventListener.apply(this, [eventType, listener, ...args]);
  };
}

React 监听的是 onClick，但在底层，它可能对应的是 click、mouseup、mousedown 等一串原生事件。

2. 事件触发的调度

当用户点击时，React 的 ReactEventListener 会接收到一个原生事件。

// 伪代码
function handleTopLevel(eventType, nativeEvent) {
  // 1. 创建合成事件
  const syntheticEvent = createSyntheticEvent(nativeEvent);

  // 2. 准备队列
  const listeners = accumulateSinglePhaseListeners(target, eventType);

  // 3. 执行监听器
  for (let i = 0; i < listeners.length; i++) {
    const listener = listeners[i];
    // 这里的 dispatch 是核心
    dispatchEvent(syntheticEvent, listener);
  }
}

3. 执行与隔离

现在，我们到了 dispatchEvent 函数。这是 stopPropagation 发威的地方。

function dispatchEvent(event, listener) {
  // 在 React 内部，它维护了一个递归调用的栈或者队列

  // 调用用户传入的函数
  listener(event);

  // 调用完当前 listener 后，React 会检查：
  // 如果当前 listener 调用了 event.stopPropagation()，React 会怎么做的？

  if (event.isPropagationStopped()) {
    // React 做了什么？
    // 它告诉下面的监听器：“兄弟，别听了，上面封了，我给你发假通知，你自己看 isPropagationStopped() 返回 true 就行。”
    // 或者更激进一点，React 会调用原生事件对象的 stopPropagation() 方法，试图从物理层面打断冒泡？
    // 实际上，React 为了性能，经常选择“拦截”而不是“物理阻断”。
    // 它会标记 isPropagationStopped = true，然后在后续派发时直接跳过。
  }
}

真相时刻：React 的 stopPropagation 是逻辑阻断，而非物理阻断。

React 的 stopPropagation 实际上非常“狡猾”。它并不一定会调用原生事件的 stopPropagation（在某些底层实现中）。它更多时候是修改了自己的内部状态，然后在执行下一个监听器之前，检查这个状态。

这就引出了 React 的核心设计哲学：逻辑隔离。

React 认为，我应该控制谁触发，谁不触发。它不信任原生 DOM 的冒泡顺序（比如 Firefox 和 IE 的区别），所以它自己重新排序了事件流。

第四部分：那个著名的“陷阱”——异步回调

这是面试必考，也是实战中 Bug 满分的重灾区。

假设你这么写：

function MyComponent() {
  const [data, setData] = useState(null);

  const handleClick = (e) => {
    e.stopPropagation(); // React 层面阻止冒泡

    // 致命操作：把事件对象保存起来，在异步里用
    const myEvent = e;

    setTimeout(() => {
      console.log('我是异步回调');
      // 尝试判断
      if (myEvent.isPropagationStopped()) {
        console.log('事件被阻止了！'); // 真的能打印出来吗？
      } else {
        console.log('事件没被阻止！'); // 实际上往往是这句！
      }
    }, 100);
  };

  return <button onClick={handleClick}>点我</button>;
}

你会惊恐地发现，打印出来的是“事件没被阻止！”

为什么？因为我们之前说了，React 使用了事件池。

当你点击时，React 创建了一个 SyntheticEvent 对象，传给 handleClick。你在函数里把它拷贝给了 myEvent。然后，handleClick 执行完毕。

React 把这个 SyntheticEvent 对象销毁了（或者重置了内部属性），并把它放回“事件池”里。下一次点击时，这个池子里的对象又活了，但它的 isPropagationStopped 属性被重置为 false 了！

这就是 React 的事件池机制造成的“时空错乱”。虽然 React 团队后来在文档里喊话让大家不要在异步里保存事件对象，但新手依然会踩坑。

修复方案：
不要在异步里用事件对象。用自定义状态：

const handleClick = (e) => {
  e.stopPropagation();
  setIsLoading(true); // 自己记个账
  setTimeout(() => {
    setIsLoading(false);
  }, 100);
};

第五部分：stopImmediatePropagation —— 绝杀技

除了 stopPropagation，还有一个大家伙叫 stopImmediatePropagation。它比 stopPropagation 强大十倍。

stopPropagation 只是说：“别往上传了。”
stopImmediatePropagation 说：“别传了！而且，在这个目标元素上，同一个事件类型的其他监听器，也别听了！”

在原生 DOM 里，这意味着它切断了捕获和冒泡，并且移除了该事件在当前目标上的监听器。

在 React 里，这更是致命的。

假设你在一个 div 上挂了两个 onClick：

<div onClick={handler1} onClickCapture={handler2}>

如果 handler2 调用了 e.stopImmediatePropagation()：

  1. React 的捕获阶段：如果 handler2 在捕获阶段触发，React 会停止后续捕获阶段的监听器执行。
  2. React 的目标阶段：handler1 不会被执行。
  3. 冒泡阶段：React 会阻止冒泡。

陷阱：
因为 React 对事件做了统一管理，如果你在 handleClickCapture（捕获阶段）里用了 stopImmediatePropagation，不仅会阻止冒泡，还会影响 React 内部可能存在的其他监听逻辑。

这是一个非常危险的 API，除非你确定你是在和原生 DOM 交互（而不是在 React 组件里），否则请慎用。

第六部分：React 18 的变化与并发模式

如果你现在用的是 React 18，情况更复杂了一点。

React 18 引入了 concurrent mode（并发模式）。这不仅仅是 UI 渲染更快了，它彻底改变了事件系统的底层逻辑。

在并发模式下，事件的处理更加复杂。React 使用了新的调度算法，可能会导致事件处理的上下文发生变化。

虽然 stopPropagation 的基本语义没有变（阻止冒泡），但在 React 18 中，“事件池”的优化被移除或改变了。

在 React 18 之前，事件对象是复用的。在 React 18 中，虽然为了性能依然有优化，但文档明确指出，不再保证事件对象是复用的，或者至少它的生命周期更加严格。

这意味着，在 React 18 中，你比以前更安全地可以在异步回调里使用事件对象，因为 React 18 可能已经放弃了激进的事件池复用策略（或者将其封装得更彻底）。

但是！ 这并不意味着你可以高枕无忧。React 18 的并发更新可能会导致你的事件处理函数被中断、重新执行或者被替换。

第七部分：实战中的“俄罗斯套娃”

让我们来看一个复杂的嵌套场景。

function Parent() {
  const handleParent = (e) => {
    console.log('Parent clicked');
    // 假设这里我们调用了原生 stopPropagation
    e.stopPropagation(); 
  };

  const handleChild = (e) => {
    console.log('Child clicked');
    // 这里 React 的 stopPropagation
    e.stopPropagation();
  };

  return (
    <div onClick={handleParent} style={{ border: '1px solid red' }}>
      <div onClick={handleChild} style={{ border: '1px solid blue' }}>
        <button>Target</button>
      </div>
    </div>
  );
}

点击按钮：

  1. React 捕获阶段：
    • handleParent 被触发。它调用了 e.stopPropagation()。
    • React 收到信号：“哦，爹封了路。”
    • React 停止了捕获阶段的后续执行。
  2. React 目标阶段：
    • handleChild 被触发。它调用了 e.stopPropagation()。
    • React 收到信号：“哦，儿子也封了路。”
  3. React 冒泡阶段：
    • React 检查：handleParent 在冒泡阶段。但是，handleParent 在捕获阶段已经 stopPropagation 了吗？
    • 答案：是的。

React 的传播逻辑是基于整个 React 事件流的。一旦在某一个节点（无论是捕获还是目标）调用了 stopPropagation，React 会认为这个事件流是“终止”的。它会跳过冒泡阶段的所有监听器。

注意： 这里有一个微妙的地方。如果你在 handleChild（目标阶段）里调用了 stopPropagation，它是否会阻止 handleParent（捕获阶段）已经执行过的逻辑？
不会。 历史无法撤销。

第八部分：源码视角的逻辑隔离实现

让我们稍微往深处看一眼 ReactEventListener 里的逻辑。我看了 packages/react-dom/src/events/ReactDOMEventListener.js 的部分源码，这是实现逻辑隔离的关键。

// 简化的核心流程
function handleTopLevel(eventType, nativeEvent) {
  // 1. 构建合成事件
  const syntheticEvent = {
    type: eventType,
    target: getClosestInstanceFromNode(nativeEvent.target), // React 树里的 Fiber 节点
    currentTarget: getClosestInstanceFromNode(nativeEvent.currentTarget), // 当前 React 节点
    nativeEvent: nativeEvent, // 原生事件，用于底层通信
    // 核心方法
    stopPropagation: function() {
      this.isPropagationStopped = true;
      // 关键点：React 会调用原生事件的 stopPropagation
      // 或者如果是为了彻底隔离，它可能调用 nativeEvent.stopImmediatePropagation
      if (this.isPropagationStopped) {
         this.nativeEvent.stopPropagation();
         this.nativeEvent.stopImmediatePropagation();
      }
    },
    isPropagationStopped: false
  };

  // 2. 收集监听器
  const listeners = getDispatchListeners(syntheticEvent.currentTarget, syntheticEvent.type);

  // 3. 执行监听器
  for (let i = 0; i < listeners.length; i++) {
    const listener = listeners[i];
    // 这是一个重要的标志：React 会检查这个标志，决定是否跳过监听器
    if (syntheticEvent.isPropagationStopped) {
       continue; // 停止传播，跳过后续监听器
    }

    listener(syntheticEvent);
  }
}

你看，逻辑隔离的核心在于 syntheticEvent.isPropagationStopped 这个标志。React 在执行 listener 之前，会检查这个标志。如果为 true，React 就直接 continue，不执行你的代码了。

这就是所谓的“逻辑隔离”。React 层面决定谁能说话，谁闭嘴。原生 DOM 的冒泡对 React 来说，只是提供了一个“触发信号”，React 自己接手了后续的流程。

第九部分：总结与避坑指南

各位老铁，今天这场讲座其实是在带大家过一遍 React 的“心里话”。

React 的 stopPropagation，本质上是一场阳谋。它通过构建自己的事件系统，剥夺了原生事件对象控制权，转而使用自己的标志位来控制执行流。

这里有几个必须要刻在 DNA 里的原则：

  1. 永远不要在异步回调里使用 React 事件对象：这是铁律。除非你确定你用的是 React 18 并且非常了解最新的 Event 对象机制，否则，用自定义变量（如 isClicked = true）来代替 e.stopPropagation() 的效果。

  2. 理解“逻辑隔离”：React 的 stopPropagation 阻止的是 React 内部的后续监听器执行，并不一定完全阻止原生 DOM 的冒泡（虽然通常会调用原生方法）。但在大多数情况下，对于 React 开发者来说，这就是“阻止”。

  3. stopImmediatePropagation 是双刃剑：它既能帮你清理垃圾代码（阻止冒泡），也能帮你制造灾难（阻止 React 内部可能需要的冒泡逻辑）。在 React 组件内，尽量少用，除非你是在操作原生 DOM 属性。

  4. React 18 的变化：拥抱并发模式。虽然代码写法没变，但心里要有数，事件处理可能会变得不那么“线性”和“同步”。

最后，React 的设计确实很精妙。它把混乱的原生世界收拾得井井有条。理解了 stopPropagation 的逻辑隔离，你就真正摸到了 React 内部的一块敲门砖。

好了，今天的讲座就到这里。希望大家下次写代码时，遇到 stopPropagation，脑海里浮现的不是简单的 e.stopPropagation()，而是 React 那个冷冰冰但又精密无比的事件调度队列。

下课！

发表回复

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