严禁全局滥用stopPropagation，因其会破坏事件流协作机制，导致组件解耦失效、React 17+竞态冲突、微前端隔离瓦解；应精准拦截“不该响应的冒泡”，而非全部冒泡。
大厂项目里严禁在全局滥用 stoppropagation，根本原因不是“它不好用”，而是它会粗暴切断事件流的天然协作机制，破坏组件解耦、干扰跨层级通信、引发微前端隔离失效，并在 react 17+ 下与原生事件产生不可控竞态。真正该阻断的是“不该响应的冒泡”，而不是“所有冒泡”。
一、破坏父子组件间受控的事件通信链
现代组件库（如 Ant Design、Element Plus）大量依赖事件冒泡实现封装内聚。例如一个 Select 组件内部的 Option 点击，需冒泡到 Select 根节点才能触发下拉关闭、值更新、onChange 回调等完整逻辑。
- 若在
Option中无差别调用e.stopPropagation()，Select将永远收不到点击信号，表现为“点了没反应”“选不中”“搜索框失焦异常” - 更隐蔽的问题是：某些 UI 库通过 document 级监听处理浮层销毁（如 Popover、Tooltip），而子组件提前截断，导致浮层悬空不消失
二、引发 React 17+ 根节点委派下的“半截冒泡”冲突
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 不是开关，而是手术刀。滥用它，等于在交通系统里随手关掉所有红绿灯——表面清静，实则瘫痪。
