最常见原因是事件未绑定到目标元素或绑定时机错误；父元素监听捕获阶段时stopPropagation()对其无效；React中须在事件处理函数内正确调用e.stopPropagation()，不可用return false替代。
为什么 stopPropagation() 有时像没起作用
最常见原因不是代码写错了，而是事件根本没绑定到你认为的目标元素上。比如 DOM 还没加载完就执行 document.getElementById('btn').addEventListener(...)，结果拿到的是 null；或者元素是动态插入的（如 React 渲染后、AJAX 加载后），但监听器在插入前就绑好了。
另一个隐蔽坑：父元素用了捕获阶段监听（addEventListener('click', handler, true)），而你在子元素里只在冒泡阶段调用 stopPropagation()——它对捕获阶段完全无效。捕获阶段事件已经从 document 走到目标了，此时再拦，为时已晚。
- 用浏览器开发者工具的 “Event Listeners” 面板，确认目标元素上真有监听器，且类型、阶段都对
- 确保绑定逻辑放在
DOMContentLoaded或useEffect(() => {}, [])（React）中 - 如果父级必须用捕获，子元素也得用捕获 + 提前调用
stopPropagation()，否则拦不住
stopPropagation() 和 preventDefault() 到底该用哪个
它们管的事完全不同：stopPropagation() 只切断传播路径，preventDefault() 只取消默认动作。混用或漏用，都会导致行为异常。
典型误配：
立即学习“前端免费学习笔记（深入）”；
- 给按钮加
e.stopPropagation()却没加e.preventDefault()→ 表单照样提交、链接照样跳转，只是父级不响应了 - 只写
e.preventDefault()→ 父级click仍会触发，但按钮不提交了，用户以为点没反应，其实是“点成功了但没提交” - 直接写
return false→ 原生 JS 中它等价于两者都调，但语义模糊；在 React 合成事件里它根本不管用
真正需要同时阻断的场景（比如点击遮罩层内按钮，既不关闭弹窗，也不跳转）才两个都写：
button.addEventListener('click', function(e) {
e.preventDefault();
e.stopPropagation();
});
嵌套可交互组件里怎么避免“一碰全动”
比如一个卡片里有展开图标、删除按钮、整卡点击跳转——点图标不该触发卡片跳转，点删除不该收起面板，更不该让外层滚动容器误判为拖拽。
这时候不能无差别 stopPropagation()，得靠 event.target 精准判断：
- 监听整张卡片的
click，但只在e.target === card时跳转（排除子元素） - 删除按钮里写
e.stopPropagation()，防止它触发卡片 click - 展开图标同理，但注意：如果图标是
<svg>里的<path>，e.target可能是 path，要用e.currentTarget或e.target.closest('.expand-btn')
比起层层拦截，用 CSS 的 pointer-events: none 关掉非交互区域的响应，往往更轻量、更可靠。
React 里 stopPropagation() 容易失效的三个点
React 的合成事件系统不影响 stopPropagation() 本身，但调用方式稍有不同：
- 必须写成
onClick={(e) => { e.stopPropagation(); doSomething(); }}，不能漏掉参数e，也不能写成onClick={doSomething}（拿不到 event 对象） - 不能在异步回调里调，比如
onClick={() => setTimeout(() => e.stopPropagation(), 0)}—— 此时事件早已冒泡完毕 - 别用
return false替代，它在 React 合成事件中不阻止冒泡，仅在原生事件中等效于preventDefault() + stopPropagation()
复杂嵌套下，真正难处理的不是“怎么拦”，而是“该不该拦”。一旦滥用 stopPropagation()，外层滚动、快捷键、焦点管理、无障碍支持都可能被意外破坏——多数时候，用委托 + target 判断，比硬拦更健壮。
