css的:hover本身不支持延时，需用transition-delay配合opacity与visibility实现视觉延迟；正确写法是hover时延迟显示、移出时立即隐藏，且二者delay值须严格配对。
hover 本身不能延时，但可以用 transition-delay 模拟延时触发
CSS 的 :hover 是即时响应的——鼠标一进入就生效，它本身不支持延迟。所谓“延时触发 hover 效果”，其实是通过控制 hover 下关联元素（比如提示框、下拉菜单、文本高亮）的显示动画来实现的视觉延迟。核心是用 transition-delay 配合 opacity 和 visibility，让效果“等一会儿再出来”。
-
opacity: 0+visibility: hidden是安全的初始隐藏组合：既不可见，也不占交互空间 -
transition-delay必须写在 hover 触发后的样式里（即.trigger:hover .tooltip），而不是默认状态中 - 只对
opacity延迟不够——用户移开鼠标时若 tooltip 还没出现，它会突然闪一下再消失；所以要同步控制visibility的切换时机 - 常见错误：把
transition-delay写在默认状态，结果 hover 一进就延迟，一出反而立刻消失
正确写法：hover 出现延迟 + 移出立即消失
这是最常用也最符合直觉的模式，适合工具提示（tooltip）、二级菜单等场景。关键在于两组 transition 声明要分开写：
.tooltip { opacity: 0; visibility: hidden; transition: opacity 0.2s ease, visibility 0s linear 0.2s; } .trigger:hover .tooltip { opacity: 1; visibility: visible; transition: opacity 0.2s ease 0.3s, visibility 0s linear 0.3s; }- 移出时：
visibility 0s linear 0.2s表示“0.2s 后立即设为 hidden”，实际就是鼠标一移开就隐藏 - 进入时：
visibility 0s linear 0.3s表示“等 0.3s 后才设为 visible”，配合 opacity 渐显，形成延迟浮现 - 数值建议：延迟 0.3–0.5s 较稳妥；太短用户感知不到，太长（＞0.7s）容易误判为无响应
想让 hover 离开后也延迟消失？那就得反向控制
有些场景（比如强调文案、高亮区域）需要“鼠标移开后还留几秒再淡出”，这时不能依赖 :not(:hover) 的过渡（它不可靠且兼容性差），而应把延迟逻辑全放在 hover 状态里，并用 js 或更稳定的 CSS 方案补位：
- 纯 CSS 可行但脆弱：给
.element默认加transition: opacity 0.5s ease 0.5s，hover 时设opacity: 1，移出后靠延迟过渡慢慢归零——但这个延迟会在 hover 开始时就启动，不符合“仅移出后延迟”的语义 - 真正可控的方式是用
@keyframes+animation-delay，把“淡出延迟”封装进动画，hover 时触发动画重置（需配合animation-fill-mode: forwards） - 更推荐方案：用
will-change: opacity提前提示渲染优化，避免延迟期间卡顿
移动端要注意：hover 在触摸设备上基本失效
所有基于 :hover 的延迟方案，在 ios safari、android chrome 等主流触摸浏览器中都不可靠——它们要么不触发 hover，要么只在点击后短暂触发一次。如果你的页面需兼容移动设备：
立即学习“前端免费学习笔记（深入）”；
- 不要单独依赖
:hover实现核心功能（比如导航菜单展开） - 延迟提示类效果，建议改用
focus-within（配合tabindex）或 JS 的mouseenter/mouseleave事件手动加 class 控制 - 如果坚持用 CSS，至少加一层降级：默认显示提示内容，hover 时才隐藏；或用媒体查询
@media (hover: hover)包裹 hover 相关样式
过渡延迟不是魔法，它是用时间差制造的错觉。最容易被忽略的一点是：**visibility 和 opacity 的 transition-delay 必须严格配对，否则会出现“看不见但能点中”或“悬停瞬间闪一下”的诡异行为**。