mouseenter/leave 不冒泡不捕获，仅在目标元素触发，专为精准悬停设计；绑定捕获或委托无效；动态场景需用 mouseover/mouseout 加 contains 判断；静态结构应直接绑定。
mouseenter 和 mouseleave 本身不冒泡，也不捕获，它们天然只在目标元素上触发，且不会因子元素触发而重复执行——这恰恰是替代传统 mouseover/mouseout（有冒泡、易误触发）的正确方式，无需手动模拟捕获或冒泡逻辑。
为什么不用捕获/冒泡来“增强” mouseenter/leave
mouseenter/mouseleave 的设计目的就是解决悬停穿透问题：当鼠标从父元素移入子元素时，mouseover 会连续触发父→子，而 mouseenter 只在真正进入父边界时触发一次，离开父边界时才触发 mouseleave。它内部已通过事件流优化实现“精确悬停”，不需要、也不支持绑定到捕获阶段或依赖冒泡传播。
- 给元素绑定
element.addEventListener('mouseenter', handler, true)—— 第三个参数true（捕获）会被忽略，浏览器仍按原语义执行 - 在父元素监听子元素的
mouseenter—— 不会触发，因为该事件不冒泡 - 试图用事件委托处理
mouseenter—— 不可行，委托依赖冒泡，而它不冒泡
正确替代方案：用事件委托 + mouseover/mouseout（谨慎判断）
如果真需要“在父容器上统一管理多个子项的悬停”，而子项是动态添加的，可回归 mouseover/mouseout，但必须手动过滤伪触发：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 检查
event.relatedTarget是否为当前元素的后代，若是，则说明只是在内部移动，不是真正进出 - 用
element.contains(event.relatedTarget)判断是否仍在内部 - 示例：父容器监听
mouseover，若!this.contains(e.relatedTarget)才视为真正进入
推荐做法：直接绑定，拥抱语义化
对静态或可预测结构的悬停交互，最简单可靠的方式就是直接在目标元素上绑定：
立即学习“Java免费学习笔记（深入）”；
btn.addEventListener('mouseenter', () => { btn.classList.add('hovered'); });btn.addEventListener('mouseleave', () => { btn.classList.remove('hovered'); });- 现代框架（React/Vue）中也应优先使用
onMouseEnter/onMouseLeave，而非onMouseOver
补充：需要捕获阶段干预？换思路
极少数场景（如全局遮罩拦截悬停、权限控制）需在鼠标进入页面任意区域前响应，可监听 document 的 mouseover 并调用 e.stopPropagation()，但注意：
– 这无法影响 mouseenter 自身行为
– 它影响的是底层的 mouseover 流，与 mouseenter 是两条并行路径
– 更合理的做法是用 CSS :hover 或状态管理控制显示逻辑，而非强依赖 JS 事件流
