别再被事件触发搞晕了：一次讲透 DOM 冒泡与捕获

相信不少前端开发者在调试页面交互时，都遇到过这样的困惑：明明只在子元素上绑定了点击事件，控制台却打印出父元素触发的日志；或者反过来，父级的点击意外“吃掉”了子级的操作。这背后的推手，就是 DOM 事件流中的冒泡（Bubbling）与捕获（Capturing）机制。

理解这套机制，不是为了背诵定义，而是为了让你在面对复杂交互时，能精准控制事件的流向，写出更健壮的逻辑。

事件的生命之旅

当你在页面上点击一个按钮时，这个事件并非瞬间完成，它经历了一场“旅行”。从最外层的 window 对象开始，向下穿透文档结构，最终到达你点击的目标元素，然后再一路返回到 window。这个过程分为三个阶段：捕获阶段、目标阶段、冒泡阶段。

大多数时候，我们默认使用的其实是冒泡阶段。比如，点击一个按钮，事件会从按钮传向它的父级容器，再传向更外层。这种设计符合直觉，因为通常我们希望知道“在这个区域里发生了什么事”，而不仅仅是那个按钮本身。

但捕获阶段往往被忽略。它是自上而下进行的，发生在事件到达目标之前。如果你需要在一个全局层面上拦截某个动作（比如在组件库中统一处理某些点击），捕获机制就能派上用场。

如何掌控事件的流向？

核心控制权就在 addEventListener 方法的第三个参数上。默认情况下，这个值是 false，意味着事件监听器注册在冒泡阶段。

如果你想让监听器在捕获阶段优先执行，只需将该参数设为 true，或者直接传入配置对象 { capture: true }。

// 默认冒泡
parent.addEventListener('click', handleClick);

// 强制进入捕获阶段
parent.addEventListener('click', handleCapture, true);

这里有个细节值得注意：同个元素上的多个监听器，顺序至关重要。 如果是同一阶段，按照注册的先后顺序执行；如果一个是捕获一个是冒泡，捕获永远先于冒泡运行。

阻断传播的边界

有时候，我们需要阻止事件继续传递，这时候常用的方法是 event.stopPropagation()。这就像是在水流中间设置了一道堤坝，水到了这里就停住了，不会继续往上涌或往下泄。

但要注意区分 e.target 和 e.currentTarget。target 是真正被点击的那个原始元素，即便事件已经冒泡到了父层，它依然指向最深处的那个子元素；而 currentTarget 则是当前正在处理事件的元素（即绑定的监听器所在的节点）。在很多事件委托场景中，利用这个差异能精准定位到具体操作的对象，而不是盲目依赖层级判断。

实战中的应用价值

掌握了理论，更重要的是怎么用。最常见的优化场景是事件委托。

想象一个包含上千个列表项的动态页面，如果给每个 li 单独绑定点击事件，不仅消耗内存，添加删除节点时还要频繁解绑和重绑监听器。更好的做法是将事件只绑定在最外层的 ul 上。

利用冒泡特性，当点击任意子 li 时，事件会冒泡到 ul。我们在 ul 的回调函数里，通过 e.target 找到实际被点击的是哪个 li，然后执行对应逻辑。这种方式极大地提升了性能，也是 React、Vue 等框架底层优化的重要思路之一。

反之，若你需要实现类似“遮罩层”的功能，确保点击子组件内部不影响父级弹窗的关闭逻辑，就需要在子组件上使用 e.stopPropagation() 来阻断冒泡。

写得更从容

DOM 事件流不是非黑即白的单选题，而是根据业务需求选择策略的工具箱。理解冒泡与捕获，本质上是理解浏览器如何处理用户行为。

下次遇到事件乱触发的问题，先别急着加防抖，试着画出事件流向图，检查一下监听器的注册阶段。把控制权拿回自己手里，代码自然会变得清爽可控。