先记住这个答案
当要在事件传播的最前端介入，比如全局点击统计、调试事件路径，或处理 focus、blur 这类不冒泡事件时，我会在 addEventListener 的第三个参数传入 true 或 { capture: true }。默认冒泡阶段适合多数交互逻辑，但捕获阶段的监听器会先于默认的冒泡阶段触发，且能覆盖目标自身及其子节点的事件。
- 捕获阶段先于目标与冒泡执行
- focus 等不冒泡事件可用捕获委托
- 全局调试或拦截需用捕获监听
捕获阶段如何提前介入事件流
DOM 事件传播依次经过捕获、目标、冒泡三个阶段。捕获阶段的监听器注册在祖先节点上，会在事件从 Window 下传至目标的过程中被触发。默认情况下 addEventListener 只注册冒泡阶段，但传入 capture: true 即可让监听器在捕获阶段执行。这意味着当事件尚未触达目标时，捕获监听器已经运行，能够对事件做出全局性的读取或拦截。
捕获阶段的执行顺序是从最外层 Window 向目标逐层收缩。任何处于事件路径上的节点都可以用捕获方式监听。值得注意，捕获与冒泡在同一节点上不冲突——如果同一事件类型在捕获和冒泡各注册一个监听器，它们都会触发，只是捕获先于冒泡。这种机制为需要“先于页面其他逻辑”执行的操作提供了确定性窗口。
用捕获监听解决不冒泡事件的委托
假设一个表单区域包含多个输入框，需求是当任意输入框获得焦点时更新侧边提示。focus 事件本身不冒泡，直接绑定在祖先容器上无法触发。若在每个输入框上单独绑定维护困难，可以利用捕获——在容器上调用 addEventListener('focus', handler, true)，事件传播虽然不冒泡，但会经过容器往下到达目标，捕获阶段能够捕获。这样只需一个监听器即可完成委托，且无需修改子元素结构。
另一个常见场景是全局点击统计。当页面有大量动态生成的按钮时，在 document 上以捕获方式监听 click 事件，可以记录包括 target 在内的传播路径。由于捕获阶段先于默认冒泡阶段，监听器能在页面其他基于冒泡的逻辑运行前取得数据。这种设计适合埋点或审计需求，但需要注意不要随意调用 preventDefault，以免阻塞业务操作。
捕获监听的失效条件与代价
如果事件在捕获途中被某个祖先节点的监听器调用 stopPropagation()，后续捕获监听器将不再执行。在调试或拦截场景中，这可能造成遗漏。因此捕获监听器应尽量放在最外层（如 Window 或 Document），减少被中止的风险。同时，捕获监听器若自身使用了 stopImmediatePropagation()，会让其他监听器失效，必须小心。
另外，所有事件在派发时都会经历捕获阶段，bubbles 属性只控制冒泡阶段。scroll、focus 等事件虽然不冒泡，但仍有捕获阶段；自定义事件即使不设置 bubbles: true，捕获监听器同样会触发。过度使用捕获会增加事件处理的复杂度，使调试变得困难。建议仅在确实需要全局或前置处理时才开启捕获，并保持监听器逻辑轻量。
容易答错的地方
- 捕获阶段不会在目标上提前执行
- 捕获监听器注册在目标自身时，事件在目标阶段触发，capture 参数不影响时机。要实现捕获阶段的提前介入，应将监听器注册在目标的祖先节点上。
- 捕获阶段可以代替冒泡
- 捕获和冒泡执行顺序不同，用途也不同。捕获面向全局介入，冒泡更贴合局部UI。用捕获处理本应在冒泡完成的任务，可能产生不可预期的先后问题。
面试官还会怎么问？
捕获监听器在目标元素自身注册时会怎样触发？
事件到达目标时不存在捕获或冒泡之分，监听器仅按注册顺序执行。在目标上指定 capture 只会影响其作为中间节点的穿透行为，对目标本身无效。
如何判断某个事件是否支持捕获阶段？
只要事件能传播（即事件路径非空），就有捕获阶段。不冒泡事件如 focus 仍可捕获，因为捕获沿路径下行。可借助 Event.composedPath() 验证路径。
捕获与事件委托结合时，event.target 和 currentTarget 有何行为？
在捕获监听器中，currentTarget 是当前注册监听的节点，target 是事件真正起源点，两者不同。可根据 currentTarget 判断在委托链上的位置。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。