事件冒泡是浏览器历史妥协形成的默认行为，源于Netscape与IE的兼容性方案，W3C将其纳入三阶段模型；不阻止时子元素事件会逐层触发父级逻辑，stopPropagation()可中断传播，事件委托依赖冒泡实现，捕获阶段则用于目标前预处理。
事件冒泡不是“设计出来”的，而是浏览器历史妥协的结果
JavaScript 的事件冒泡机制并非刻意为之的“高级特性”，它源于 90 年代 Netscape（捕获优先）和 IE（冒泡优先）两大阵营对事件处理路径的互不兼容。W3C 最终在 DOM2 Events 标准中把两者合并为三阶段模型：捕获 → 目标 → 冒泡。冒泡阶段被保留为默认行为，根本原因就一条：addEventListener 第三个参数不传或传 false 时，浏览器必须有个确定、一致、向后兼容的执行顺序——冒泡就是那个“默认答案”。
不手动阻止冒泡，子元素点击会意外触发父级逻辑
这是日常开发中最常踩的坑：给列表项加删除按钮，结果一点击，整个列表容器也响应了折叠动作；或者弹窗里的按钮点一下，背后遮罩层也跟着关闭了。现象本质是事件从 button 冒泡到 div.modal 再到 body，每层都绑了 click 处理器。
- 用
event.stopPropagation()可立即中断传播路径，只影响当前事件流，不影响默认行为（比如链接跳转） - 别再用过时的
event.cancelBubble = true—— 它只在老 IE 生效，现代标准已废弃 - 注意：如果父元素监听的是
document级别事件（比如全局快捷键），stopPropagation()无效，得用event.stopImmediatePropagation()
事件委托正是靠冒泡才真正实用
你不需要给每个 li 单独绑定 click，只要在 ul 上监听一次，靠 event.target 判断点的是哪个子项——这之所以可行，全因冒泡把子元素的事件“送上来”了。
- 动态添加的
li无需重新绑定，天然支持 - 1000 个列表项，只占 1 个监听器内存，而非 1000 个
- 但要注意：如果中间某层调用了
stopPropagation()，委托就断了——排查时重点检查父级是否误拦
捕获阶段不是“替代方案”，而是补充时机
想在事件到达目标前做预处理？比如权限校验、日志埋点、或拦截未登录用户的操作，就得用捕获：element.addEventListener('click', handler, true)。它和冒泡不是二选一，而是同一事件流的两个“窗口期”。
立即学习“Java免费学习笔记（深入）”；
- 捕获阶段从
document开始，依次经过html→body→ 父容器 → … → 目标元素 - 冒泡阶段则反向：目标 → 父容器 →
body→html→document - 同一个元素上同时注册捕获和冒泡监听器，捕获一定先于冒泡执行，哪怕代码写在后面
stopPropagation() 的调用时机，或混淆捕获/冒泡的执行顺序，比理解“为什么有冒泡”更容易导致线上问题。 
