事件捕获是事件流的第一阶段，从window向目标元素逐层下行，需显式启用capture: true；它与冒泡方向相反、时机在前，适用于全局预处理，而事件委托依赖冒泡因其天然支持子元素事件向父元素传递。
事件捕获是事件流的“第一站”，从 window 向目标元素逐层下行
事件捕获不是备选方案，而是事件传播中真实存在的、早于目标阶段的阶段。当你点击一个嵌套的 button，浏览器会先从 window 开始，依次经过 document → html → body → 父容器 → 目标元素，这个过程就是捕获阶段。
它默认不生效——你必须显式启用：
element.addEventListener('click', handler, true);
// 或更现代写法：
element.addEventListener('click', handler, { capture: true });- 只对支持
addEventListener的现代浏览器有效（IE9+，所有主流现代浏览器均无兼容问题） - DOM0 级绑定（如
onclick = fn）**完全不支持捕获**，只走冒泡 - 捕获阶段的监听器在目标阶段之前执行，哪怕目标元素上也有同类型监听器
捕获 vs 冒泡：方向相反，时机不同，用途天然分化
它们不是“两种可互换的写法”，而是事件流中不可跳过的两个阶段，顺序固定：捕获 → 目标 → 冒泡。
-
方向：
capture: true是由外向内（window→ 目标），capture: false（默认）是由内向外（目标 →window） - 典型用途：捕获适合全局预处理（比如统一拦截表单提交前校验权限），冒泡适合响应式操作（比如列表项点击后高亮、删除）
- 共存无冲突：同一元素可同时在捕获和冒泡阶段监听同一个事件，二者都会触发，只是顺序不同
-
阻止传播行为不同：
e.stopPropagation()会同时中断当前阶段后续路径（含捕获或冒泡），但不影响同阶段已注册的其他监听器；而e.stopImmediatePropagation()会立刻终止该阶段所有剩余监听器
事件委托为什么只依赖冒泡，而不是捕获？
事件委托的本质是“父元素代子元素收事件”，这只有在子元素事件能自然到达父元素时才成立——而冒泡正提供了这种向上传递的能力。
立即学习“Java免费学习笔记（深入）”；
捕获做不到这点：它从外往里走，父元素的捕获监听器会在子元素之前触发，此时你拿到的 e.target 确实是子元素，但逻辑上它还没“落到”子元素身上，容易造成语义错乱（比如想对被点击的 li 做操作，却在父 ul 的捕获阶段就执行，而此时子元素可能还未完成渲染或初始化）。
- 委托必须用冒泡：
list.addEventListener('click', e => { if (e.target.matches('li')) { /* 处理 */ } }); - 若误用捕获绑定委托逻辑，
e.target虽正确，但时机过早，且违背委托“等事件真正发生后再响应”的直觉 - 动态添加的子元素自动享受委托，前提是它们能正常冒泡（注意：CSS 的
pointer-events: none会彻底中断冒泡）
容易被忽略的关键细节
很多人调试时卡在“为什么我绑了捕获没反应”，其实问题常出在细节上：
- 父级元素没有设置
capture: true，但子元素用了——捕获阶段根本不会走到子元素（因为捕获是自上而下，子元素监听器只在它自己被“路过”时才触发） - 混用
onclick和addEventListener时，前者永远只在冒泡阶段运行，无法与捕获监听器形成对称控制 - 在捕获阶段调用
e.preventDefault()是有效的（比如阻止链接跳转），但它发生在目标阶段之前，需确认是否真要在此刻干预 - Vue/React 等框架的合成事件系统内部已封装事件流，直接操作原生捕获/冒泡需小心绕过框架机制，否则可能失效或重复触发
捕获不是“高级冒泡”，它是事件流中一条独立、前置、有明确用途的通路；理解它不为炫技，而是在需要提前介入（如埋点、权限、防误触）时，手上有把准头够的刀。
