指南：深度拆解大厂项目里严禁在全局滥用 stopPropagation 的核心原因-js教程-PHP中文网

严禁全局滥用stoppropagation，因其会破坏事件流协作机制，导致组件解耦失效、react 17+竞态冲突、微前端隔离瓦解；应精准拦截“不该响应的冒泡”，而非全部冒泡。

大厂项目里严禁在全局滥用 stoppropagation，根本原因不是“它不好用”，而是它会粗暴切断事件流的天然协作机制，破坏组件解耦、干扰跨层级通信、引发微前端隔离失效，并在 react 17+ 下与原生事件产生不可控竞态。真正该阻断的是“不该响应的冒泡”，而不是“所有冒泡”。

现代组件库（如 Ant Design、Element Plus）大量依赖事件冒泡实现封装内聚。例如一个 Select 组件内部的 Option 点击，需冒泡到 Select 根节点才能触发下拉关闭、值更新、onChange 回调等完整逻辑。

若在 Option 中无差别调用 e.stopPropagation()，Select 将永远收不到点击信号，表现为“点了没反应”“选不中”“搜索框失焦异常”
更隐蔽的问题是：某些 UI 库通过 document 级监听处理浮层销毁（如 Popover、Tooltip），而子组件提前截断，导致浮层悬空不消失

React 17 将事件委派点从 document 下移到 #root。这意味着：原生事件仍在 document 上监听，而 React 合成事件只管 #root 内部——两者不再同源，但物理冒泡路径仍重叠。

你在子组件中调用 e.stopPropagation()，只能阻止 React 合成事件冒泡到 #root 父级，无法阻止原生事件继续向 document 上传
若外层有原生 document.addEventListener('click', hideAllModals)，你的按钮点击仍会触发隐藏逻辑——看似阻断了，实则失效
结果就是：开发者以为“已拦截”，实际业务逻辑照常执行，问题难复现、难定位

当多个 React 应用共存（如 qiankun 子应用），每个子应用有自己的 #root-xxx。它们的事件委派互不干扰，靠的就是“各管各的根节点”。

若某子应用在内部随意 stopPropagation，看似只影响自己，但若其组件被父应用以 portal 方式挂载到父应用 DOM 中，事件冒泡路径就跨出了自身 #root
此时阻断行为可能意外截断父应用期望捕获的全局操作（如快捷键统一处理、无障碍焦点管理、主题切换广播）
更严重的是：某些微前端框架依赖事件冒泡做生命周期同步，滥用 stopPropagation 会导致子应用卸载失败、资源泄漏

真正需要的不是禁止冒泡，而是明确“谁该响应、谁不该响”。优先使用语义化、声明式、可维护的替代方式：

用 event.currentTarget === event.target 判断是否命中本体：适合容器内多区域响应不同逻辑（如卡片整体跳转 + 内部按钮点赞）
给目标元素加专属 class 或 data 属性，配合事件委托过滤：例如 document.addEventListener('click', e => { if (e.target.matches('[data-ignore-global]')) return; })
用 pointer-events: none 或 disabled 控制原生交互态：比 JS 阻断更底层、更稳定，且不影响语义和可访问性
在合成事件中用 e.nativeEvent.stopImmediatePropagation()（慎用）：仅当确认需同时阻止同级其他原生监听器时才考虑，非默认推荐

不复杂但容易忽略：stopPropagation 不是开关，而是手术刀。滥用它，等于在交通系统里随手关掉所有红绿灯——表面清静，实则瘫痪。