各位，大家晚上好！欢迎来到今天的“React 源码深度解剖实验室”。
我是你们的主讲人，一个在代码世界里摸爬滚打多年，被各种事件冒泡折磨得死去活来，最后终于决定跟这些浏览器行为死磕到底的资深工程师。
今天，我们要聊的话题非常硬核，非常“物理”，甚至有点像是在解构一个间谍惊悚片。我们要聊的主角，就是那个我们每天都会用到，但往往知其然不知其所以然的——stopPropagation()。
你们是不是经常在写代码时遇到这种坑：
“我明明调用了 e.stopPropagation()，为什么父组件的点击事件还是被触发了？为什么我的弹窗关不掉？为什么我的 :active 样式在 React 里失效了？”
别慌，今天我就要剥开 React 的层层外衣，带你看看这个函数在源码深处到底干了什么。我们要揭示的真相是：所谓的“物理隔离”，其实是一场精心策划的“信息封锁”。
准备好了吗？让我们把键盘敲得噼里啪啦响，开始这场源码探秘之旅。
第一部分：原生 DOM 的混乱世界（以及为什么它很吵）
在 React 出现之前，或者当我们直接操作原生 DOM 时，世界是混乱的。想象一下，你有一个 HTML 结构，长得像俄罗斯套娃一样嵌套：
<div id="grandparent">
<div id="parent">
<button id="child">点击我</button>
</div>
</div>如果你给这个 button 加上了一个点击监听器，当用户点击它时，会发生什么？这就是经典的事件冒泡。
- 点击事件首先到达
button。 - 然后，浏览器会像吹气球一样，把这个事件冒泡到
parent。 - 接着，继续冒泡到
grandparent。 - 最后，一直冒泡到
document，甚至window。
在这个过程中，如果你在每一个层级都加了监听器，它们都会被依次触发。这就是 DOM 的“广播机制”。
为了阻止这种混乱，原生 JS 提供了 e.stopPropagation()。这就像是在某个层级竖起了一道墙，告诉浏览器：“嘿，别往上面传了！我听完了！”
但是！ React 出现了。React 介入之后，事情就变得有点“魔幻现实主义”了。
第二部分：React 的“上帝视角”与事件委托
React 为什么要这么做？因为它懒。哦不，它是因为性能和跨浏览器兼容性。
React 不想给你的每一个 div、span、button 都去绑定原生监听器。那内存得爆炸成什么样？于是，React 采用了事件委托。
简单来说，React 只在根节点（比如 document 或 root）上绑定了一个监听器。当你在屏幕任何地方点击时，React 的监听器都会先接收到这个事件。
然后，React 会根据你写的 JSX 结构（虚拟 DOM），一层一层地“向下”遍历（或者叫“向下分发”），看看是谁触发了这个事件。如果发现是 button，它就执行 button 的 onClick 回调；如果是 div，就执行 div 的 onClick。
在这个过程中，React 创建了一个合成事件。这个合成事件是一个 JavaScript 对象，它模拟了原生事件的行为，但是它是 React 自己管理的。
这就引出了今天的核心矛盾：
当你调用 e.stopPropagation() 时，你到底是在阻止谁的冒泡？是阻止原生 DOM 事件的冒泡，还是阻止 React 合成事件的冒泡？
答案可能会让你大吃一惊。
第三部分：源码解密——stopPropagation 的物理隔离真相
为了看清真相，我们需要潜入 React 的源码深处。虽然我们不能真的去翻阅几万行代码，但我可以带你看看 ReactEventListener 和 SyntheticEvent 的核心逻辑。
1. 事件是如何到达 React 的？
当你在浏览器点击一个按钮时，原生事件首先到达了 React 在根节点挂载的那个监听器。
// ReactEventListener.js (伪代码示意)
function handleTopLevel(topLevelType, nativeEvent) {
// 1. React 收集所有相关的 React 事件监听器
// 2. 构建一个“事件池”或者说是合成事件对象
const event = constructSyntheticEvent(nativeEvent);
// 3. 开始分发
// 这里的 propagationPhase 是 'bubbling' (冒泡阶段)
processEventQueue(event, topLevelType, 'bubbling');
}2. 分发过程：冒泡的模拟
React 遍历虚拟 DOM 树，从目标节点（比如那个 button）开始，沿着父节点链一直向上找。在这个过程中，它会检查每一层节点是否有对应的 onClick 处理函数。
// processEventQueue (伪代码示意)
function processEventQueue(event, topLevelType, propagationPhase) {
// 获取当前事件的目标节点
let targetNode = event.target;
// 模拟冒泡：从当前节点往父节点遍历
while (targetNode) {
// 检查这个节点有没有 React 绑定的监听器
const listeners = getReactListenersForType(topLevelType, targetNode);
if (listeners.length > 0) {
// 执行监听器
listeners.forEach(listener => listener(event));
// --- 关键时刻 ---
// 如果事件被标记为停止传播，React 就会跳过这个节点及其父节点的监听器
if (event.isPropagationStopped()) {
// React 停止遍历，不再去调用父组件的逻辑
return;
}
}
// 移动到父节点
targetNode = targetNode.parentNode;
}
}看懂了吗？这就是“物理隔离”的真相。
当你在子组件里写 e.stopPropagation() 时，React 的代码逻辑是：
- 它构建了一个
SyntheticEvent对象。 - 它调用你的
onClick处理函数，把SyntheticEvent传给你。 - 你的函数里调用了
e.stopPropagation()。 - React 的监听器检查
event.isPropagationStopped()。 - 结果为
true。 - React 说：“好嘞，我不找父组件了，我回家吃饭了。”
结论 1： stopPropagation() 成功阻止了 React 合成事件的冒泡。这意味着，父组件的 onClick 不会被触发。
3. 但是，浏览器知道吗？
让我们把视线移回 constructSyntheticEvent(nativeEvent) 这一步。
React 构造合成事件时，通常会保存对原生事件的引用。这个引用通常通过 e.nativeEvent 暴露出来。
function constructSyntheticEvent(nativeEvent) {
const syntheticEvent = {
// ... 其他属性
nativeEvent: nativeEvent, // 这里保存了真实的浏览器事件对象
isPropagationStopped: function() {
return this.isPropagationStoppedNative; // React 自定义的标志位
},
stopPropagation: function() {
this.isPropagationStoppedNative = true; // 设置标志位
// --- 关键补充 ---
// 为了保持“物理隔离”的完整性，React 通常也会调用原生事件的 stopPropagation
// 但这取决于具体的实现细节和版本（React 18+ 有所优化）
if (this.nativeEvent.stopPropagation) {
this.nativeEvent.stopPropagation();
}
}
};
return syntheticEvent;
}等等！ 这里有个巨大的坑！React 的实现虽然通常会尝试同步调用原生事件的 stopPropagation，但这并不是百分之百保证的，尤其是在异步操作或者某些极端的浏览器行为下。
更重要的是，即使 React 调用了原生事件的 stopPropagation，如果第三方库或者你自己直接在 DOM 上绑定的原生监听器，它们可能并不在 React 的“控制范围”之内。
让我们看一个更具体的例子。
第四部分：实战演练——打破隔离
假设你有这样一个场景：
import React, { useState } from 'react';
export default function TestComponent() {
const [parentCount, setParentCount] = useState(0);
const [childCount, setChildCount] = useState(0);
const handleParentClick = () => {
console.log('🔥 父组件被点击了！');
setParentCount(c => c + 1);
};
const handleChildClick = (e) => {
console.log('🔥 子组件被点击了！');
setChildCount(c => c + 1);
// 我要阻止冒泡！
e.stopPropagation();
};
// 模拟原生 DOM 监听器
const nativeDivRef = React.useRef(null);
React.useEffect(() => {
if (nativeDivRef.current) {
// 这里直接绑定在原生 DOM 上，绕过了 React 的事件系统
nativeDivRef.current.addEventListener('click', () => {
console.log('🧱 原生监听器：我被触发了！React 没拦住我！');
});
}
}, []);
return (
<div onClick={handleParentClick} style={{ padding: '20px', border: '2px solid red' }}>
<div ref={nativeDivRef} style={{ padding: '20px', border: '2px solid blue' }}>
<button onClick={handleChildClick} style={{ padding: '10px' }}>
点击我
</button>
</div>
</div>
);
}运行结果分析：
- 你点击按钮。
- React 事件系统接收到事件。它找到了
button的onClick（handleChildClick），执行了它，并且检测到e.stopPropagation()。 - React 在遍历虚拟 DOM 树时，遇到
handleChildClick执行完毕，检查isPropagationStopped为true。 - React 决定：不执行
div的onClick（handleParentClick）。 - 但是！ 那个
div（蓝色边框）上有一个原生监听器（addEventListener）。 - 浏览器底层的原生事件机制依然在运行。虽然 React 可能调用了原生事件的
stopPropagation，但在 React 的合成事件处理完逻辑之后，浏览器的原生事件流可能依然存在残留，或者 React 的调用时机不如原生绑定那样“霸道”。
结果：
控制台输出：
🔥 子组件被点击了！🧱 原生监听器：我被触发了！React 没拦住我！（注意：父组件的handleParentClick没有输出，被 React 阻止了，但原生监听器依然存活）。
这就是物理隔离的局限性。React 建立了一道墙，挡住了其他 React 组件的视线，但它无法完全控制浏览器这个混乱的底层世界，尤其是那些“非法入侵”的原生监听器。
第五部分：stopImmediatePropagation 的恐怖之处
为了彻底摧毁你的世界观，我必须再介绍一个更狠的函数：stopImmediatePropagation()。
这个函数和 stopPropagation 有什么区别？
stopPropagation: 停止传播（冒泡）。stopImmediatePropagation: 停止传播（冒泡）并且 停止同节点的其他监听器。
如果同一个 DOM 节点上有多个监听器（一个原生，一个 React 绑定），stopImmediatePropagation 会阻止 React 的监听器执行，但依然可能允许原生监听器执行（取决于绑定的顺序）。
这就像是在一个房间里，你按下了“静音键”（stopPropagation），房间里其他人的声音（React 组件）确实停了。但是，如果你按下了“物理断电键”（stopImmediatePropagation），或者有一个疯子直接扯掉了电线（原生监听器），房间里的噪音可能依然存在。
第六部分：为什么 React 要这么做？（性能与哲学）
你可能会问：“为什么 React 不直接调用原生事件的 stopPropagation 就完事了？为什么要搞得这么复杂？”
这就涉及到 React 的哲学了。
React 的核心思想是可预测性和一致性。浏览器的事件系统是混乱的（IE 和 Chrome 的冒泡顺序可能都不一样，某些浏览器的事件对象属性五花八门）。如果你直接依赖原生事件，你的代码在不同浏览器上表现会不一致。
React 想要一个“纯净”的事件环境。
- 统一性：无论你在 Chrome 还是 Firefox，
e.stopPropagation的行为都是一样的。 - 性能：通过事件委托，React 只需要维护一棵树的事件监听器，而不是成百上千个。
但是，这种“隔离”也带来了副作用：开发者往往高估了隔离墙的坚固程度。
当你在 React 中使用 stopPropagation 时，你是在告诉 React：“在这个层级之后，不要分发任何 React 事件。”但你并没有告诉浏览器：“在这个层级之后，不要处理任何原生事件。”
这就是为什么有时候你会发现：
- 你的 CSS 动画在 React 事件处理完之前就停止了（因为 React 阻止了事件冒泡，导致某些基于事件驱动的 CSS 动画逻辑没跑完）。
- 第三方库（比如 jQuery、D3.js）如果监听了原生事件，可能会在你意想不到的时候触发。
第七部分：源码细节——事件池的幽灵
再深入一点，React 的合成事件对象其实还有一个很著名的特性——事件池。
在旧版本的 React 中（React 16 之前），所有的 SyntheticEvent 对象都是从一个池子里取出来的。
// 伪代码示意
const eventPool = [];
function constructSyntheticEvent(nativeEvent) {
// 从池子里拿一个对象
const event = eventPool.pop() || new SyntheticEvent();
// 填充数据
event.nativeEvent = nativeEvent;
event.type = nativeEvent.type;
// ...
// 重置状态
event.isPropagationStopped = false;
return event;
}
function releaseSyntheticEvent(event) {
// 把对象还给池子
// 重置所有属性
event.nativeEvent = null;
event.isPropagationStopped = false;
// ...
eventPool.push(event);
}这有什么关系？
当你调用 e.stopPropagation() 时，你不仅设置了一个标志位 isPropagationStopped = true，你还在告诉 React：“这个对象用完了，可以回收了。”
如果在 stopPropagation 之后，你试图访问 e.target 或者 e.nativeEvent，在旧版本中可能会得到 null 或者旧的数据，因为对象已经被回收并重置了。这就是为什么 React 官方文档总是警告你：不要在事件回调中保存合成事件的引用，一定要在回调执行完立即使用它。
虽然 React 18+ 对事件池做了一些优化（不再使用固定池，而是复用对象），但“复用”这个概念依然存在。stopPropagation 在这个回收过程中扮演了“清理现场”的角色。
第八部分：如何优雅地应对这种隔离？
既然知道了真相，我们该怎么写代码？
-
不要过度依赖
stopPropagation：
在 React 中，尽量通过条件渲染（&&、三元运算符）或者状态控制来决定是否渲染父组件的监听器，而不是依赖stopPropagation。这样逻辑更清晰。❌ 错误示范：
<div onClick={handleParent}> <button onClick={(e) => { e.stopPropagation(); handleChild(); }}> 点击 </button> </div>✅ 推荐示范：
{showChild && ( <div onClick={handleParent}> <button onClick={handleChild}>点击</button> </div> )} -
警惕原生监听器：
如果必须使用原生监听器，确保你也调用了原生事件的stopPropagation，或者明确知道这种隔离失效的后果。<div onClick={handleParent}> <button onClick={handleChild} onMouseDown={(e) => { // 如果这里调用了 stopImmediatePropagation，React 的 handleChild 也不会执行 e.stopImmediatePropagation(); // 但原生监听器依然可能执行 }} > 点击 </button> </div> -
善用
useEffect清理：
如果你用useEffect绑定了原生监听器，记得在return函数里移除它。这能防止内存泄漏，也能防止监听器在组件卸载后依然“鬼魂般”地触发事件。
第九部分：总结——物理隔离的哲学
好了，伙计们，让我们把镜头拉远。
React 的 stopPropagation 并不是一道绝对的黑洞。它更像是一个选择性过滤器。
- 它在 React 的内部世界里，是一道铁闸门，切断了父组件与子组件的通讯。
- 它在浏览器的外部世界里，只是一次礼貌的敲门，如果外面还有人没听到敲门声（原生监听器），他们依然会自己干自己的。
这就是 React 源码细节中关于 stopPropagation 的物理隔离真相。
它让我们写出了更一致、更优雅的代码，但也让我们在某些时候与浏览器最底层的物理机制产生了隔阂。
所以，下次当你按下 e.stopPropagation() 时，请记住：你并不是切断了整个世界的连接，你只是切断了 React 这个小圈子里的广播信号。 而在这个小圈子之外，浏览器依然在按它自己的规则运行。
希望今天的讲座能让你对 React 的事件系统有一个全新的、更具“物理质感”的理解。记住，代码不仅仅是逻辑，更是对现实世界规则的模拟和妥协。
现在，去代码里找找那些隐藏的 stopPropagation 吧，看看它们是不是真的像它们表现出来的那样“强大”。如果你发现它们失效了，别怪代码，那是浏览器在跟你开玩笑！
下课！