事件冒泡本质是从目标元素逐级向上触发父元素相同事件监听器，核心是event.target始终不变、event.currentTarget指向当前执行监听器的元素。
事件冒泡在复杂嵌套结构中，本质是“从目标元素出发，逐级向上触发父元素的相同事件监听器”，顺序固定、可预测。关键不是死记路径，而是抓住两个核心：**事件目标（event.target）始终不变**，**当前处理阶段的 this 或 event.currentTarget 指向正在执行监听器的那个元素**。
一、先确认冒泡路径：从 target 到 document
冒泡路径由 DOM 树结构决定，与事件绑定方式无关。例如：
<div id="a">
<div id="b">
<button id="c">点我</button>
</div>
</div>
点击 button#c 后，冒泡路径为：#c → #b → #a → body → html → document。可用 event.composedPath() 在任意监听器中打印验证（返回从 target 开始的完整冒泡节点数组）。
二、区分 event.target 和 event.currentTarget
这是分析顺序混乱的根源：
立即学习“Java免费学习笔记（深入）”；
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- event.target：始终是最初被触发的元素（如 button#c），整个冒泡过程中不会变
- event.currentTarget：当前正在执行监听器的那个元素（如在 #b 上触发时，它就是 #b）
常见误判：看到 console.log(e.target.id) 总是 "c"，就以为事件“只发生在 c”，其实监听器是在 a/b/c 各自节点上分别执行的——只是每次拿到的 target 相同而已。
三、监听器执行顺序取决于绑定位置，而非代码书写顺序
同一事件类型（如 click）在不同节点上的监听器，严格按冒泡路径顺序执行：
- 即使你在
#a上先写监听器、再给#c绑定，点击时仍是#c → #b → #a - 同一节点上多个同类型监听器，按绑定先后顺序执行（
addEventListener的第三个参数为false或省略时） - 若某层调用
e.stopPropagation()，冒泡立即中断，后续祖先节点监听器不再触发
四、调试技巧：快速定位触发链
在每个关键父容器监听器中加一句：
element.addEventListener('click', e => {
console.log(
'target:', e.target.id,
'| current:', e.currentTarget.id,
'| phase:', e.eventPhase // 1=捕获, 2=目标, 3=冒泡
);
});
配合浏览器开发者工具的 Event Listeners 面板，能直观看到哪些节点绑定了什么事件、是否启用捕获——尤其适合排查第三方库或框架动态插入的节点。
不复杂但容易忽略：冒泡顺序只和 DOM 层级与事件类型有关，和 JS 执行时机、变量作用域、甚至是否使用箭头函数都无关。盯住 target 和 currentTarget，再看 composedPath，路径就清晰了。
