hover延迟失效表现为菜单闪退或断连，根源在于缺乏防抖缓冲；应通过opacity/visibility配合transition-delay控制隐藏延迟，禁用display/height过渡，js需区分show/hide定时器，移动端须检测hover支持并改用点击逻辑。
hover 延迟失效的常见表现
鼠标刚移过去菜单就弹出，但稍微一抖就收回去；或者移向子菜单时中途断连，二级菜单闪退——这不是 CSS 写错了，是缺乏延迟缓冲。纯 :hover 没有防抖机制，浏览器对“离开”和“进入”的判定极其敏感，尤其在父项与子菜单之间存在 1px 空隙、或子菜单定位偏移时，mouseleave 会立刻触发。
用 CSS transition-delay 实现 hover 延迟
延迟必须作用于“隐藏”动作，而非“显示”。直接给 display 加 delay 没用（它不支持过渡），正确做法是控制 opacity 和 visibility，配合 transition-delay：
-
.dropdown-content初始设为opacity: 0; visibility: hidden;，并加transition: opacity 0.2s ease, visibility 0.2s step-end; -
.dropdown:hover .dropdown-content设为opacity: 1; visibility: visible; - 关键：在隐藏状态上加
transition-delay: 0.3s;，即鼠标移出后等 300ms 再执行隐藏 - 不要对
display或height做延迟过渡，它们无法动画，且会破坏可访问性
JavaScript fallback 中的 clearTimeout 延迟管理
当需要兼容旧浏览器或添加键盘支持时，JS 控制更灵活，但容易漏掉 clearTimeout 导致多个定时器冲突：
- 每次
mouseenter触发时，先clearTimeout(this._showTimer)，再this._showTimer = setTimeout(() => {...}, 200) - 每次
mouseleave触发时，先clearTimeout(this._hideTimer)，再this._hideTimer = setTimeout(() => {...}, 300) - 必须区分 show/hide 两个 timer，共用一个变量会导致 hide 被 show 覆盖
- 如果菜单支持多级嵌套，每个层级都要维护独立 timer，不能全局共享
移动端不适用 hover-delay 的根本原因
延迟方案只对桌面端有效。iOS Safari 和 Android Chrome 在真机上基本不响应 :hover —— 点击后不会维持悬停态，transition-delay 完全不触发。此时强行套用 desktop 延迟逻辑，只会让触屏用户点一次没反应、再点才展开，体验更差。
真正要做的，是在检测到 matchMedia("(hover: none) and (pointer: coarse)").matches 时，直接禁用所有 hover 相关样式和 JS 延迟逻辑，改用 click 或 pointerdown + classList.toggle("show") 控制显隐。别试图用 JS 模拟 hover 延迟，那只是把 desktop bug 复制到 mobile。
最常被忽略的是：延迟值不是越长越好。超过 400ms 用户会觉得卡顿，低于 200ms 又起不到防误触作用。实测 250–300ms 是多数场景下的平衡点，但必须配合 position: relative 和无间隙 DOM 结构才有意义。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
