事件流的三阶段：捕获、目标与冒泡详解

事件流的三阶段——捕获、目标与冒泡——是浏览器处理用户交互时事件在DOM树中不可跳过、不可颠倒的自然传播路径：它像一滴水落入池塘，先自上而下“沉降”（捕获），精准触达被操作元素（目标），再由内而外“泛起涟漪”（冒泡）。这一机制不仅支撑了权限校验、日志记录等全局预处理，也成就了高效灵活的事件委托实践；理解它，就是掌握了前端交互底层逻辑的钥匙——无论你是想精细控制事件时机，还是写出更健壮、可维护的事件处理代码，这三段式流动都至关重要。

事件流的三阶段是浏览器处理用户交互（比如点击、输入）时，事件在 DOM 树中传播的完整路径。它不是人为“设计”的流程，而是规范定义的自然过程——就像水滴落进池塘：先下沉（捕获），触底（目标），再泛起涟漪向上扩散（冒泡）。

捕获阶段：从外到内，提前拦截

事件从 window 开始，逐层向下经过 document、html、body，直到抵达被点击的真实元素。这个阶段本身不触发默认行为（比如表单提交），但如果你在某一层级用 addEventListener(type, handler, true) 显式注册了捕获监听器，它就会在此时执行。

• 适合做全局预处理，比如权限校验、日志记录，且不想被子元素干扰
• 父元素的捕获监听器总比子元素的先运行（即使子元素代码写在前面）
• 日常开发中很少主动使用，因为多数逻辑关心的是“谁被点了”，而不是“谁可能拦下这个点”

目标阶段：事件真正发生的位置

当事件到达你实际操作的那个 DOM 节点（比如一个按钮），就进入目标阶段。此时无论你用 true 还是 false 注册监听器，只要类型匹配（如 'click'），都会触发。

• 这是唯一一个“既算捕获又算冒泡”的阶段：它既是捕获链的终点，也是冒泡链的起点
• 如果同一个元素同时绑定了捕获和冒泡监听器，目标阶段会按注册顺序依次执行（先加的先运行）
• 可通过 event.eventPhase === 2 在回调中准确判断当前是否处于此阶段

冒泡阶段：从内到外，层层响应

事件完成目标后，并不会停止，而是反向向上，经过父元素、祖父元素……最终回到 window。这就是冒泡阶段。我们熟悉的事件委托（比如给 ul 绑 click 监听来管理所有 li），正是依赖这一机制。

• 绝大多数传统写法（onclick、element.onclick = fn）只工作在冒泡阶段
• 可调用 event.stopPropagation() 中断后续冒泡，但不影响已触发的捕获或目标阶段监听器
• 注意：不是所有事件都冒泡（如 focus、blur、mouseenter 默认不冒泡），需查 MDN 确认

整个过程不可跳过，也不能颠倒顺序：一定是捕获 → 目标 → 冒泡。你只能选择在哪一阶段挂载自己的监听器，而不能让冒泡先于捕获发生——除非你在同一元素上故意把冒泡监听器写在捕获监听器前面，但这只是改变了同阶段内的执行次序，不改变事件流本身的三段结构。

今天关于《事件流的三阶段：捕获、目标与冒泡详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！