事件冒泡和捕获是浏览器固定执行的三段式流程：先捕获（window→目标）、再目标阶段、最后冒泡（目标→window）；stopPropagation()仅阻断当前阶段，stopImmediatePropagation()可终止全部；事件委托依赖冒泡向上传递，捕获不适用。
事件冒泡和捕获不是“二选一”，而是浏览器固定执行的两个阶段
点击一个嵌套按钮时，浏览器会**先从 window 开始向下走（捕获），再在目标元素上触发（目标阶段），最后从目标向上回传（冒泡）**。这个三段式流程是硬编码在 DOM 规范里的，你不能跳过捕获或只留冒泡——只能决定监听器在哪个阶段响应。
关键区别就三点：
• 方向相反：捕获是 window → document → body → 父 → 子；冒泡是 子 → 父 → body → document → window
• 时机固定：捕获一定早于目标阶段，目标阶段一定早于冒泡
• 启用方式不同：冒泡是默认行为（addEventListener('click', fn) 或 addEventListener('click', fn, false)）；捕获必须显式声明（addEventListener('click', fn, true) 或 { capture: true }）
为什么 stopPropagation() 有时没效果？
它只中断「当前阶段」的后续传播路径，不影响其他阶段。比如你在捕获阶段调用 e.stopPropagation()，目标阶段和冒泡阶段都会被直接跳过；但如果你在目标阶段调用，冒泡阶段就停了，捕获和目标本身已执行完毕。
- 常见误判：给父元素绑了捕获监听器，又在子元素里调用
stopPropagation()，结果父元素捕获仍触发了——因为子元素的监听器根本不在捕获阶段，它压根没参与捕获过程 - 真正想“封死整个事件流”，得用
e.stopImmediatePropagation()，它连同级其他监听器也一并掐断 -
preventDefault()和传播控制完全无关，它只管阻止默认行为（如表单提交、链接跳转）
事件委托为什么必须用冒泡，不能用捕获？
事件委托的本质是“让父元素代收子元素的事件”，这依赖子元素的事件能自然到达父元素——而只有冒泡提供这种向上传递能力。
立即学习“Java免费学习笔记（深入）”；
捕获是从外往里走，父元素的捕获监听器会在子元素之前触发。此时 e.target 虽然是子元素，但事件还没真正“落到”它身上，DOM 可能还没完成渲染，逻辑上容易错乱。比如你想高亮被点击的 <li>，在父 <ul> 的捕获阶段就执行，很可能操作了一个尚未 ready 的节点。
正确写法始终是：list.addEventListener('click', e => { if (e.target.matches('li')) { /* 处理 */ } });
现代写法推荐用 { capture: true } 而不是 true
addEventListener 第三个参数现在支持对象形式，比布尔值更清晰、可扩展（未来可能加 once、passive 等）。虽然 true 还能用，但 { capture: true } 是当前标准写法，也避免和旧版 IE 兼容层混淆。
注意：onclick="..." 这类 DOM0 级绑定**完全不支持捕获**，只走冒泡；所有捕获逻辑必须用 addEventListener。
另外，动态插入的新元素自动享受冒泡委托，但若父容器设置了 pointer-events: none，冒泡会被彻底截断——这点常被忽略。
