捕获先于冒泡，事件流分为捕获、目标、冒泡三阶段；默认addEventListener在冒泡阶段执行，设第三个参数为true才在捕获阶段响应；stopPropagation()可阻止后续传播，但需谨慎使用以免破坏事件委托等正常逻辑。
事件冒泡和捕获到底谁先发生？
事件不是“直接触发”就完事的——它会走完整个事件流：先从 window 往下走（捕获阶段），到达目标元素（目标阶段），再从目标往上回传（冒泡阶段）。这是 W3C 标准定义的三段式流程，**捕获一定先于冒泡**，哪怕你没显式监听捕获，它也真实存在。
- 默认所有
addEventListener绑定的事件处理函数，都在**冒泡阶段**执行（第三个参数省略或为false） - 只有主动把第三个参数设为
true，才能在捕获阶段响应事件 - IE8 及更早版本只支持冒泡，不支持捕获；现代浏览器全部支持三阶段
为什么点击子元素，父元素的 click 也被触发了？
这就是典型的**事件冒泡现象**：你点的是 #child，但事件会自动顺着 DOM 树一路向上，依次触发 #parent、#grandparent、document、window 的同类型监听器。
- 常见误操作：给弹窗遮罩层和内部按钮都绑了
click，结果一点按钮，遮罩层也响应并关闭弹窗 - 根本原因：没在按钮的事件处理器里阻止传播，导致事件继续冒泡到遮罩层
- 这不是 bug，是机制设计——事件委托正是靠它实现的
stopPropagation() 怎么用才不踩坑？
在事件处理函数中调用 event.stopPropagation()，就能立刻中断当前事件在 DOM 中的后续传播（无论处于捕获还是冒泡阶段）。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
document.getElementById('child').addEventListener('click', function(event) {
console.log('子元素被点击');
event.stopPropagation(); // ✅ 关键这一行
});
document.getElementById('parent').addEventListener('click', function() {
console.log('父元素不会被触发');
});
- 注意：
event.preventDefault()是阻止默认行为（如表单提交、链接跳转），跟冒泡无关，别混用 -
event.stopImmediatePropagation()更狠：不仅阻止冒泡，还会跳过当前元素上其他同类型监听器（比如两个click监听器，第二个根本不会执行） - 旧版 IE（≤IE8）不支持
stopPropagation，需兼容时得加event.cancelBubble = true
什么时候该阻止、什么时候不该阻止？
阻止传播不是万能解药，滥用反而破坏交互逻辑。关键看事件是否「本应只属于这个元素」。
立即学习“Java免费学习笔记（深入）”；
- ✅ 应该阻止：下拉菜单项点击、模态框内按钮、自定义右键菜单中的选项
- ❌ 不该阻止：表格行点击高亮（你可能希望点击单元格也能高亮整行）、卡片内点赞按钮（父卡片可能有「查看详情」逻辑）
- ⚠️ 容易忽略：如果父元素用了事件委托（比如
ul.addEventListener('click', handler)），而你在子元素里stopPropagation()，委托就失效了——这时应改用条件判断而非粗暴阻止
stopPropagation()，它就变成一个精确控制点；用错位置，轻则功能异常，重则整个交互链断裂。最稳妥的做法是：**先确认事件是否真该止步于此，再动手加那行代码。** 
