stopPropagation 只挡 React 合成事件派发链，组件内 addEventListener 的原生监听照跑。React 17 把委托点从 document 挪到 root 容器，混用场景执行顺序直接翻转。
面试题：线上事件冒泡出问题，stopPropagation 不生效，弹窗关不掉，页面交互乱套，你怎么排查？
候选人答得顺：React 是合成事件，阻止冒泡调 e.stopPropagation() 就行。
面试官追问：调了还是拦不住呢？
场面崩了。
很多人对 React 事件机制的理解停在“React 是合成事件，做了事件委托”。这句话没错，但它解释不了任何线上故障。真正要命的是合成事件和原生事件混用时的执行顺序，不是“React 是不是合成事件”这个概念。
先看代码：为什么 stopPropagation 挡不住
这段代码看起来很正常：
function Modal() {
const ref = useRef(null);
useEffect(() => {
const onDocClick = () => {
console.log('document 原生监听触发');
closeModal(); // 直接被关掉
};
document.addEventListener('click', onDocClick);
return () => document.removeEventListener('click', onDocClick);
}, []);
return (
<div ref={ref} onClick={(e) => e.stopPropagation()}>
点我，别关弹窗
</div>
);
}
点一下 div，弹窗还是关了。stopPropagation 明明调了。
它挡的是 React 自己的合成事件派发链。<div> 上的 onClick 和 document 上的 addEventListener 属于两套完全独立的冒泡体系。React 的 stopPropagation 只能让 React 不再向上派发合成事件，管不到原生 DOM 已经走过的路。
执行顺序才是命门
React 17 之后，事件委托点是 root 容器，不是 document。一次点击从 DOM 冒泡到 React 派发合成事件，链路是这样：
sequenceDiagram
participant U as 用户
participant Inner as 组件内原生监听
participant Root as React 委托点 root 容器
participant Doc as document 原生监听
U->>Inner: 点击按钮 原生冒泡开始
Inner->>Inner: 执行 addEventListener 回调
Inner->>Root: 事件冒泡到 root 容器
Root->>Root: React 派发合成事件 执行 onClick
Root->>Doc: 继续冒泡到 document
Doc->>Doc: 执行 document 上的原生监听
看清楚了：组件内绑的原生监听，在 React 合成事件回调执行之前就已经跑完。
这时候在 onClick 里调 e.stopPropagation()，只能往后拦，拦到 root 之上、document 之上的部分。往前已经结束的监听，无从追回。
这不是“方法没调对”，是时序问题。
要掐断原生冒泡，得用合成事件对象上的 nativeEvent：
onClick={(e) => {
e.stopPropagation(); // 合成事件链：不再向上派发
e.nativeEvent.stopPropagation(); // 原生链：不再向上冒泡
e.nativeEvent.stopImmediatePropagation(); // 同一节点上后续监听器也跳过
}}
四个追问，一个比一个深
面试的本质是一串追问链。原视频里那四个问题，基本就是分水岭：
| 追问 | 答不上来暴露什么 |
|---|---|
| 调了 stopPropagation 还是拦不住怎么办 | 不知道合成事件与原生事件是两套体系 |
| 原生监听和合成事件谁先执行 | 没有执行时序的心智模型 |
e.stopPropagation 和 e.nativeEvent.stopPropagation 区别 | 分不清事件对象类型 |
| React 17 事件委托改了什么，会带来什么坑 | 没用版本意识看框架升级风险 |
第四个问题答完，基本就结束了。能答完这四个的候选人，和只背过定义的候选人，不在一个量级。
线上排查：别凭感觉，先打印
线上真出问题，光知道原理没用，得有可执行的排查动作。下面这条路径覆盖大多数混用场景：
flowchart TD
A[现象 线上点击交互异常] --> B[打印事件对象]
B --> C{是 SyntheticEvent 还是原生 Event}
C -->|SyntheticEvent| D[检查是否混绑原生监听]
C -->|原生Event| E[检查监听绑定的节点层级]
D --> F[确认执行先后顺序]
E --> F
F --> G{stopPropagation 是否生效}
G -->|否| H[改用 nativeEvent.stopPropagation]
G -->|是| I[检查 React 版本与委托点]
H --> J[加标志位临时止损]
I --> J
J --> K[代码评审阶段拦截混用写法]
先打印事件对象，确认你手上拿的是哪一个。是 SyntheticEvent 还是原生 Event，决定后面所有判断的方向。这一步看着笨，但线上排查最怕凭感觉。
再理清捕获与冒泡的执行顺序，尤其是捕获阶段的原生事件和冒泡阶段的合成事件，谁在前谁在后。很多“冒泡拦不住”不是拦不住，是执行顺序跟预期反了。
React 16 到 17：委托点一变，顺序全翻
这是最容易埋雷的地方。React 16 及之前，事件委托挂在 document；React 17 之后，挂在 root 容器上。
| 维度 | React 16 及之前 | React 17 及之后 |
|---|---|---|
| 委托节点 | document | root 容器 |
| 与 document 原生监听的相对顺序 | 同节点，按注册先后 | 合成事件先，document 监听后 |
| 多 React 应用嵌套 | 顶层统一接管 | 各自 root 各自接管 |
| 升级风险 | - | 依赖 document 冒泡的库要回归 |
升级版本必须做事件回归。老代码里有一堆挂在 document 上的原生监听，尤其第三方库。React 16 时代它们的执行顺序可能符合预期，升到 17 之后顺序翻转，测试环境不一定复现，上线才发现。
修复优先级：先保主流程，再修边角
线上出故障，不是所有问题都值得立刻发版。
- 核心交互：弹窗、表单提交、下拉选择这类直接影响用户操作的，P0，紧急修复
- 非核心：埋点、日志上报这类时间统计问题，可以跟版本迭代一起修
先保证主流程可用，再谈根治。
遇到老代码临时改不动，可以加标志位做事件过滤止损：
let guard = false;
function safeStop(handler) {
return (e) => {
if (guard) return;
guard = true;
try {
handler(e);
} finally {
setTimeout(() => { guard = false; }, 0);
}
};
}
这是创可贴，不是解药。同时要把“合成事件和原生事件随意混用”写进 CodeReview 检查项，从源头减少这类故障。
弹窗类组件尤其危险。很多 UI 库内部就是用 addEventListener 实现点击外部关闭，一旦你的业务代码也在同一层级混绑，冲突几乎必然发生。
面试官真正在考什么
不是你会不会背“React 是合成事件”，而是三层：
第一层，能不能分清事件对象类型，从而定位故障的真实根因，而不是盲目复制 stopPropagation。
第二层，知不知道版本差异带来的坑，清楚冒泡捕获的完整执行顺序。
第三层，有没有故障止损、CodeReview、业务规避这类工程落地经验。
普通前端的解法是复制粘贴 stopPropagation，不好使就加 if 判断硬编码。大厂前端给的是从复现、排查、修复到规范规避的一整套治理思路，扛得住组件嵌套、第三方库混用、框架版本升级。
这个就叫专业。
一句话收束：stopPropagation 管的是 React 的派发链，nativeEvent.stopPropagation 管的才是 DOM 的冒泡链，混用场景下先看时序，再谈拦截。
写在最后
你们线上遇到过 React 合成事件和原生监听打架吗？最后是靠调整绑定层级、换用 nativeEvent，还是靠标志位兜底挡住的？评论区聊聊。
有用的话点个赞。
