原生 title 的延迟由浏览器决定，无法通过 html 或 css 修改；chrome/firefox/edge 通常在悬停后 500–1000ms 触发，且不可配置，也不生成 dom 节点，css 无法干预；移动端无 hover 逻辑，延迟更不适用；如需可控延迟，必须用 js 监听 mouseenter/leave 配合 settimeout 实现。
原生 title 的延迟由浏览器决定，无法通过 HTML 或 CSS 修改
写了 title="提示" 却发现鼠标一停就弹、或等太久才出现？这不是你代码的问题，而是浏览器自己定的规则。Chrome、Firefox、Edge 通常在悬停后 500–1000ms 触发提示，这个时间不可配置——title 属性本身不接受任何延迟参数，也不存在 data-delay、tooltip-delay 这类标准属性。
常见误区是试图用 CSS 给 title 加 transition-delay，但没用：它根本不生成 DOM 节点，CSS 选不到、动不了、过渡不了。
- 别在
title上写style="transition: opacity 0.3s 1s"—— 完全无效 - 别指望加
delay类名或自定义属性能改变行为 - 移动端（尤其 iOS Safari）压根不走悬停逻辑，延迟更无从谈起
想控制延迟？必须用 JS，不能靠 title
真正可控的延迟方案只有一种：用 JavaScript 监听 mouseenter 和 mouseleave，配合 setTimeout 手动控制显隐时机。这样既能设「进后 300ms 显示」，也能设「出后 200ms 隐藏」，还能解决鼠标滑向提示框时闪退的经典断连问题。
关键不是“怎么加 delay”，而是怎么避免误触发：
- 每次
mouseenter都要先clearTimeout(hideTimer)，否则快速进出会导致提示卡住 - 显示和隐藏必须用独立定时器，且隐藏前得先清掉显示定时器
- 提示框本身要加
pointer-events: none，否则鼠标移过去会意外触发mouseleave - 若支持键盘导航，还得监听
focus/blur，并用aria-describedby关联提示元素
为什么 CSS :hover + transition-delay 不可靠
有人用伪元素 + transition-delay 模拟延迟，比如：.tip::after { transition-delay: 0.6s; }。这只能做到「显示延迟」，隐藏仍是即时的；更重要的是，它依赖 :hover 状态，在移动端完全失效——iOS 和安卓 WebView 基本不响应 :hover，连带整个方案归零。
还有几个隐形坑：
-
transition-delay只对可动画属性生效（如opacity），对display或visibility的切换无效 - 如果提示框用了
position: absolute但父容器有transform，z-index 很容易被新层叠上下文吃掉 - 伪元素热区没扩展的话，鼠标从触发元素移到提示框途中会丢失
:hover，导致一闪即逝
真正容易被忽略的：延迟感知 ≠ 用户意图
设个 300ms 延迟不是为了“看起来高级”，而是匹配用户真实操作节奏：太快（800ms）用户已经移走了。更关键的是，原生 title 的延迟在不同系统上浮动极大——Windows 上可能 600ms，macOS 上可能 900ms，而部分 Linux 发行版甚至默认禁用该提示。
如果你的提示承载的是操作后果（如“删除后不可恢复”）、快捷键说明（如“Ctrl+S 保存”）或动态数据（如库存数），那就别纠结延迟了——title 本身就不该出现在这些场景里。它只是兜底语义，不是交互界面。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
