本文详解如何在嵌套列表结构中精确绑定 mouseover 事件，确保仅当鼠标真正悬停在顶层菜单项（如 Element 1–4）本身时触发，而忽略其子菜单（如 2.1、4.2 等），核心在于区分 event.target 与事件监听元素。
本文详解如何在嵌套列表结构中精确绑定 mouseover 事件，确保仅当鼠标真正悬停在顶层菜单项（如 element 1–4）本身时触发，而忽略其子菜单（如 2.1、4.2 等），核心在于区分 `event.target` 与事件监听元素。
在处理多级导航菜单时，一个常见误区是：为父 <li> 元素添加 mouseover 监听器后，鼠标移入其内部子元素（如子菜单 <ul> 或子项 <li>）时，事件仍会“看似触发”——这并非事件被错误绑定，而是由于 mouseover 事件默认具有冒泡特性，且监听器实际附加在父元素上，只要鼠标进入该父元素的任意后代区域，事件对象就会被派发到该父元素监听器中。
你原代码中的选择器：
const mainElems = document.querySelectorAll('div > ul > li:not(ul)')语义上存在逻辑错误：:not(ul) 并不能筛选“不包含 <ul> 子元素”的 <li>，因为 :not() 是对当前匹配元素自身进行否定判断，而非对其子节点。此处 li:not(ul) 实际等价于 li（因 <li> 永远不会是 <ul>），因此它仍会选中 Element 2 和 Element 4 这类包含子菜单的顶层项——而这正是问题根源：它们既是监听目标，又包裹了子菜单区域。
plan-family-law-practice-local-seo-faq-cluster
下载
调研本地常见问题，将其归类为若干主题簇，并为家事法律业务撰写可直接上线的 FAQ 内容。适用于开展针对……的本地 SEO 工作。
✅ 正确解法不是靠 CSS 选择器排除“有子菜单”的项，而是在事件处理器中主动校验事件源头：
const mainElems = document.querySelectorAll('div > ul > li');
mainElems.forEach(element => {
element.addEventListener('mouseover', (event) => {
// 关键判断：仅当鼠标直接悬停在当前 li 元素本身（而非其任意后代）时才响应
if (event.target === element) {
console.log(element.innerText.trim()); // .trim() 避免日志含多余空白
}
});
});⚠️ 注意事项：
- 不要使用 event.stopPropagation()（如原代码所示）：它会阻止事件向父级冒泡，但此处无需阻止冒泡，且对 mouseover 的“精准触发”无帮助；
- event.target 指向鼠标实际进入的最深层 DOM 节点（如点击 <li>Element 2.1</li> 时，target 就是该子项元素），而 element 是监听器绑定的顶层 <li>；二者相等，才代表鼠标正位于该顶层项的直接内容区（即文本或直接子节点，不含子菜单区域）；
- 若需增强健壮性（例如支持空格/图标等内联子元素），可扩展判断：event.target.closest('li') === element，但本例结构简单，严格全等已足够。
? 总结：DOM 事件的精准控制依赖于对 event.target 的显式校验，而非依赖 CSS 选择器“预过滤”。理解事件流（捕获→目标→冒泡）与目标元素（target）和当前处理元素（this / element）的区别，是解决此类交互问题的关键。
