原生title属性的悬停延迟由浏览器硬编码决定，Chrome/Firefox/Edge为500–1000ms且不可配置；它不生成DOM节点，CSS无法干预，移动端因无hover机制而失效；可控方案需用JS监听事件配合setTimeout，或采用aria-describedby+role="tooltip"实现无障碍兼容的自定义提示。
title属性的延迟是浏览器定死的，改不了
Chrome、Firefox、Edge 对 title 的触发延迟固定在 500–1000ms，这个值由渲染引擎硬编码决定，title 属性本身不接受任何 delay 参数，CSS 也选不到它——因为它根本不生成 DOM 节点。你写 style="transition-delay: 200ms" 或加 data-delay 属性，全无效。
常见误操作包括：
- 给
title元素套transition，结果毫无反应 - 用
:hover+transition-delay伪元素模拟，只做到“显示延迟”，隐藏仍是瞬时的，且移动端完全失效 - 以为加个
setTimeout就能“增强”原生title，实际只是覆盖了它——一旦你监听mouseenter，就已脱离原生路径
移动端根本没 hover，title 形同虚设
iOS Safari 和主流安卓 WebView 基本不响应 title 悬停：没有 hover 状态，长按唤起的是系统菜单（复制/分享），不是提示框。哪怕你在桌面端调好了延迟和文案，一上手机就归零。
若必须支持触控设备，得换触发逻辑：
立即学习“前端免费学习笔记（深入）”；
- 用
touchstart+setTimeout模拟长按（建议阈值 ≥ 600ms，防误触） - 同时保留
mouseenter/focus以兼容键盘与鼠标用户 - 别只监听
touchend——手指抬起才触发太晚，用户已经移开了
真正可用的无障碍平替：aria-describedby + 自定义 tooltip
放弃 title 不等于放弃可访问性；相反，用 aria-describedby 关联真实 DOM 提示元素，才能让屏幕阅读器读出内容、键盘用户 Tab 进入、高对比度模式正常渲染。
最小可行结构示例：
<button aria-describedby="tip-1">删除</button> <div id="tip-1" role="tooltip" hidden>删除后不可恢复</div>
关键约束：
-
role="tooltip"必须配aria-describedby，否则读屏软件跳过 - tooltip 元素要挂载在
document.body下，避免被overflow: hidden父容器裁切 - 组件卸载时必须手动
remove()tooltip 元素，否则内存泄漏 - 不要用
display: none隐藏 tooltip——会令屏幕阅读器彻底忽略它
容易被忽略的细节：提示不能是唯一信息通道
无论你用 title、CSS 伪元素还是 JS tooltip，只要提示文案承载关键操作后果（如“将清空所有缓存”）、法律声明或步骤指引，就必须同步提供显式文本——比如放在按钮旁、折叠面板内或表单校验旁。因为：
- 屏幕阅读器可能跳过
title或读错顺序 - 放大镜模式下，原生提示常被界面边缘裁掉
- 用户无法选中、复制、翻译或搜索
title文本
真正健壮的提示，从来不是“悬停才出现”的那个浮层，而是页面结构里始终可见、可聚焦、可交互的一部分。
