DOM 事件捕获与冒泡：一场被设计出来的分层通信协议

不只是知道怎么用事件，更要知道浏览器为什么这样设计 ，框架如何在其上构建通信机制 ，以及它如何影响我们做前端架构决策。

📌目录

浏览器事件模型的设计动机：一场分布式通信架构演化史
事件捕获与冒泡阶段的底层实现与执行栈原理
为什么"目标阶段"不提供独立监听？
事件委托的正确范式与性能陷阱
React / Vue 是如何劫持与重构事件系统的？
事件机制与 Shadow DOM 的穿透边界探讨
停止传播 vs 停止默认：两套机制的系统意义
架构师思维：事件系统是前端的"中间件"吗？

🧱 1. 浏览器事件模型的设计动机

💬 背景

浏览器的事件系统不是天生就这么设计的，它是一种后期演进出的结构性抽象。早期网页是静态的，没有事件系统；随着动态需求增多，才有了 DOM Level 2 Events。

核心目标是两个：

支持分布式 UI 模块通信：你不需要每个元素绑定逻辑，而是靠"传播"机制监听感兴趣的阶段。
提供统一处理机制：比如弹窗关闭、点击穿透、页面跳转阻止等，都可以"拦截"或"劫持"。

它的哲学很像现代微服务系统里的"拦截器 + 路由 + 通知"模式。

⚙️ 2. 捕获与冒泡的底层执行机制

当用户与 DOM 交互，浏览器执行事件处理流程如下（内部伪代码模拟）：

csharp 复制代码

dispatchEvent(targetElement, event) {
  const path = getPropagationPath(targetElement);

  // Phase 1: Capturing
  for (let i = 0; i < path.length; i++) {
    invokeListeners(path[i], event, { phase: 'capturing' });
    if (event.cancelled) return;
  }

  // Phase 2: Target
  invokeListeners(targetElement, event, { phase: 'at-target' });

  if (event.cancelled) return;

  // Phase 3: Bubbling
  for (let i = path.length - 1; i >= 0; i--) {
    invokeListeners(path[i], event, { phase: 'bubbling' });
    if (event.cancelled) return;
  }
}

🧠 注意：

每个 addEventListener 本质上是绑定一个监听器到 listenersMap[element][eventType][phase]。
浏览器内部维护一份 path ------ 也就是事件传播路径，这是个缓存链表，性能考虑非常关键。
stopPropagation() 和 stopImmediatePropagation() 其实是在修改 event 对象状态，让传播流程提前终止。

❓3. 为什么没有"target-only"阶段监听器？

很多人希望有：

php 复制代码

target.addEventListener('click', handler, { phase: 'only-target' });

但 W3C 没有设计这套 API，是因为：

捕获和冒泡已能覆盖所有场景；
增加"target-only"会让事件路径判断变复杂，缓存失效；
框架内部可以轻松模拟该行为，所以浏览器层面不提供是合理的"去冗余设计"。

🚀 4. 事件委托：性能好，但不是银弹

委托是性能优化工具，但有坑：

⚠️ 误区：

委托位置不当 ：绑定到 document 的代价是 DOM 树遍历更远，尤其在 Shadow DOM 中会失效。
频繁检查 e.target 可能导致热路径退优化（JIT 优化器无法预测类型）。
动态变化时要做 selector 匹配缓存，否则会带来性能下降。

✅ 最佳实践：

委托绑定到稳定容器，避免跨 Shadow Boundary。
使用 e.target.closest(selector)，比自己构造循环判断更快更语义化。
利用事件"分发节流"（event delegation batching）机制，自行实现批量处理。

🧬 5. React / Vue 是如何"劫持"事件系统的？

React 的合成事件（SyntheticEvent）

React 并不直接绑定在组件上，而是统一挂载到容器（如 #root）：

arduino 复制代码

// 内部：document.addEventListener('click', reactEventHandler)

然后通过虚拟 DOM 映射事件 → 再调用组件内部逻辑。

优点：

支持跨平台（RN、Web 等统一机制）
统一事件池对象，减少 GC
模拟事件冒泡，兼容旧浏览器

缺点：

一旦阻止事件传播，可能影响多个组件行为；
调试时堆栈被封装，不容易 trace 到 native DOM。

Vue 的事件模型

Vue 保留了原生事件能力，但在组件间提供了 $emit 事件流，不走原生 DOM：

ini 复制代码

<Child @custom-event="handle" />

这是一种组件通信协议，和 DOM 冒泡无关。

🧩 6. Shadow DOM 与事件隔离

在 Shadow DOM 中，默认事件冒泡被"封装"：

xml 复制代码

<my-component>
  #shadow-root
    <button></button>
</my-component>

<button> 的 click 不会冒泡到 <my-component> 的外部。
除非设置 composed: true，事件才会穿透 Shadow Boundary。

arduino 复制代码

new CustomEvent('someEvent', {
  bubbles: true,
  composed: true,
});

这让我们可以设计"组件边界事件"，也就是局部冒泡 + 显式公开的分层通信策略。

🧭 7. 架构视角：事件系统 ≈ 中间件层

从架构角度看，事件系统可以被抽象为一种 分布式的中间件通信机制：

事件对象 ≈ 请求上下文（Context）
捕获阶段 ≈ Pre Hook
冒泡阶段 ≈ Post Hook
委托监听器 ≈ 路由网关
stopPropagation ≈ 拦截器中断链路

这也是现代框架大量使用事件机制构建插件、组件通信系统的根本原因。

✅ 小结

事件捕获与冒泡，从来不是"点击一个按钮会发生什么"这么简单的问题。

它是浏览器底层通信协议的体现，背后是：

系统设计哲学
性能优化考量
架构解耦手段
跨框架兼容策略