父元素收不到点击事件是因为子元素阻断了冒泡，应优先用e.target与e.currentTarget区分目标和绑定节点，或改用capture: true捕获阶段监听，避免滥用stopPropagation。
点击事件被子元素吞掉，父元素收不到怎么办
这是最典型的冒泡中断场景：给 div 套了 button 或 span，绑在 div 上的点击回调从不执行。根本原因是子元素触发了事件，但没让事件继续向上冒泡到父级。
解决方法不是删掉子元素事件，而是控制传播路径：
- 子元素事件处理器中显式调用
e.stopPropagation()—— 但这是“堵”，容易引发后续维护问题 - 更稳妥的是改用捕获阶段监听：给父元素绑定时传入
{ capture: true } - 或者统一用冒泡，但子元素只做自己该做的事，不调用
stopPropagation()，靠e.target和e.currentTarget区分真实点击目标
addEventListener 的第三个参数到底怎么选 true / false
false（默认）走冒泡阶段，true 走捕获阶段——这直接决定谁先响应、能否拦截。
常见误用是以为 true 就是“优先执行”，其实它只是提前介入，未必适合所有场景：
- 表单内嵌按钮：想让外层
form在用户点任何内部控件前统一做权限校验？用{ capture: true } - 模态框遮罩层：点击遮罩关闭弹窗，但不想影响里面按钮的点击？遮罩层用冒泡，按钮也用冒泡，靠
e.target === e.currentTarget判断是否点在遮罩上 - 避免滥用
capture: true：它会拦截所有子元素的同类型事件，包括你没预料到的第三方组件内部事件
e.target 和 e.currentTarget 总是搞混？它们的区别在哪
e.target 是你真正点击的那个 DOM 节点；e.currentTarget 是当前这个事件处理器所绑定的那个节点。嵌套结构里二者经常不同。
这是解耦嵌套点击逻辑的核心依据：
- 父容器绑一个点击事件，内部有多个
li，不用给每个li单独绑 —— 在回调里判断e.target.tagName === 'LI' - 如果
e.target是子元素的子元素（比如svg > path），用e.target.closest('li')向上找最近匹配项 - 别用
e.target.parentNode硬推层级，DOM 结构一变就失效
阻止默认行为和阻止冒泡容易一起乱用
e.preventDefault() 和 e.stopPropagation() 解决的是两类问题，混用会导致意料之外的行为。
典型翻车现场：
- 在自定义下拉菜单的
click里同时调用了两个方法，结果导致页面滚动失效（preventDefault影响了body的原生滚动） - 用
stopPropagation拦截了点击，但忘了某些场景下还需要让表单提交或链接跳转 —— 这时候应该用e.target类型判断，而不是无差别拦截 - 移动端要注意：
touchstart阶段就preventDefault，可能直接禁掉整个页面滑动
嵌套点击冲突的本质不是“谁该响应”，而是“谁该负责哪一层逻辑”。把事件流看作一条管道，捕获是上游阀门，冒泡是下游出口，而 e.target 是流经此处的水滴本身——真正难的是在复杂 DOM 树里准确定位那滴水来自哪片叶子，又该往哪个支路导流。
