事件冒泡遵循明确的捕获→目标→冒泡三阶段路径，从最内层触发元素开始逐级向上，需结合dom层级、监听注册位置及addeventlistener第三个参数判断执行时机。
事件冒泡在复杂嵌套结构中不是靠“猜”，而是靠明确的传播路径和阶段判断。关键在于理清 DOM 层级关系、事件监听注册位置，以及每个阶段（捕获 → 目标 → 冒泡）的实际触发顺序。
看清 DOM 嵌套层级与事件目标
冒泡从实际被点击（或触发）的那个最深元素开始，不是视觉上最显眼的，而是结构上最内层的节点。比如点击一个 <span></span>，即使它被包裹在五层 <div> 里，冒泡也从 <code><span></span> 开始，依次经过它的父、祖父……直到 document 或 window。
建议做法：
- 用浏览器开发者工具（Elements 面板）右键目标元素 → “Scroll into view”，确认它在 DOM 树中的真实位置
- 在事件回调中打印
event.target和event.currentTarget：前者永远是初始触发元素，后者是当前绑定监听器的元素 - 对深层嵌套结构，可临时加一句
console.log(event.target.tagName, event.currentTarget.tagName)快速区分
识别监听器注册在哪一层、哪个阶段
同一个事件类型（如 click），可能在多个层级都绑了监听器，但是否触发、何时触发，取决于 addEventListener 的第三个参数：
-
el.addEventListener('click', handler)或... , false→ 冒泡阶段执行 -
el.addEventListener('click', handler, true)→ 捕获阶段执行 - 同一元素上多个监听器按注册顺序执行（捕获阶段先注册的先执行，冒泡阶段也是）
注意：目标阶段（即 event.target === event.currentTarget）既属于捕获终点，也属于冒泡起点，所以目标元素上的监听器，无论第三个参数是 true 还是 false，都会执行一次（现代浏览器行为）。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
用日志验证完整事件流顺序
面对三层以上嵌套（比如 body > section > article > ul > li > button），光看代码容易混乱。直接加带标识的日志最可靠：
- 在每一层元素上分别添加监听器，并标注阶段和层级：
console.log('button - target')、console.log('li - bubbling')、console.log('ul - bubbling')等 - 若某层用了
true参数，就写成console.log('section - capturing') - 实际点击后，控制台输出顺序就是真实传播路径：捕获阶段由外向内 → 目标 → 冒泡阶段由内向外
快速定位干扰源：重复绑定或未阻止传播
复杂结构中常出现“点一下触发多次”或“本不该响应却响应了”，多数源于：
- 同一元素被多次
addEventListener（尤其在循环或组件重渲染时没清理） - 某个中间层监听器没调用
event.stopPropagation()，导致本该终止的冒泡继续向上 - 误把
event.preventDefault()当作阻止冒泡用（它只阻止默认行为，比如表单提交或链接跳转）
排查时优先检查：触发点的父级中，是否有监听器遗漏了 stopPropagation；是否在动态插入节点后重复绑定了监听器而未解绑。
