事件流严格按捕获→目标→冒泡三阶段执行：捕获从document逐层至目标父级，目标阶段执行该元素所有监听器，冒泡从目标逐层回传至document；监听器仅在注册阶段响应。

事件捕获和冒泡在复杂嵌套结构中的执行顺序，本质是由 DOM 树层级关系和事件监听器绑定阶段共同决定的，不是看视觉层叠，而是严格按 HTML 结构的父子关系走。只要理清三个阶段的路径和监听器注册位置，就能准确预测执行顺序。

先确认事件流的固定三阶段

每次用户触发一个支持事件流的交互（如 click、keydown），浏览器一定按以下顺序推进：

• 捕获阶段：从 document 开始，逐层向下经过 html → body → 祖父元素 → 父元素，直到目标元素的直接父级（不包括目标自身）
• 目标阶段：事件抵达实际被点击/触发的那个元素（e.target），执行它上面所有绑定在捕获或冒泡阶段的监听器（此时 useCapture 值不影响执行，都会触发）
• 冒泡阶段：从目标元素自身开始，逐层向上经过父元素 → 祖父元素 → body → html → document

关键：监听器在哪一阶段注册，就只在那一阶段响应

同一个元素上可以同时存在捕获和冒泡监听器，它们互不干扰，各自只在对应阶段运行：

jm-jsjkxyjs02-zlm-405

使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。

下载

• el.addEventListener('click', fn, true) → 只在捕获阶段触发
• el.addEventListener('click', fn, false) 或省略第三个参数 → 只在冒泡阶段触发
• 目标阶段会把该元素上所有监听器都执行一遍，不管 useCapture 是 true 还是 false

例如，对 <div id="child"></div> 同时绑定：
child.addEventListener('click', () => console.log('捕获'), true);
child.addEventListener('click', () => console.log('冒泡'), false);
点击它时，控制台会输出：
捕获（目标阶段执行）
冒泡（目标阶段执行）

多层嵌套下，执行顺序 = 阶段路径 + 注册位置

以这个结构为例：

<div id="A">
  <div id="B">
    <button id="C">点我</button>
  </div>
</div>

假设全部用 addEventListener 绑定 click 监听器：

• A 捕获：A.addEventListener('click', ... , true)
• B 冒泡：B.addEventListener('click', ... , false)
• C 捕获：C.addEventListener('click', ... , true)
• C 冒泡：C.addEventListener('click', ... , false)

点击 C 后完整执行顺序是：

1. A 捕获（捕获阶段：document → A → B → C 的父级，A 在路径上）
2. B 捕获？→ 没有绑定，跳过
3. C 捕获（目标阶段前最后一步捕获，但标准中目标元素自身不参与捕获，所以这其实是目标阶段触发的捕获监听器）
4. C 冒泡（目标阶段同时触发的冒泡监听器）
5. B 冒泡（冒泡阶段：C → B → A → document）
6. A 冒泡（同上）

注意几个易错点

• focus / blur / scroll / change 等事件不冒泡，即使结构再深，也只在目标阶段执行一次
• stopPropagation() 阻断的是后续阶段的传播，比如在捕获阶段调用，后续的目标和冒泡阶段都不会发生；在目标阶段调用，则冒泡阶段完全失效
• 同一阶段多个监听器，按注册先后顺序执行，与 DOM 层级无关
• 事件委托依赖冒泡：把监听器放在父级（如 ul），靠子元素（li）触发后冒泡上来，再用 e.target 判断来源，这是性能优化的核心逻辑