tooltip与toast本质不同：tooltip依赖dom绑定和悬停触发，生命周期由鼠标事件控制；toast独立存在、主动触发且自动消失，混用会导致交互错乱。
HTML气泡（Tooltip）和消息提示（Toast）本质不同
不是命名差异，是交互逻辑、触发方式、生命周期完全独立的两类组件。混用会导致行为错乱，比如把 Tooltip 当 Toast 用，用户点一下就消失，结果悬停又弹出来，体验割裂。
触发机制决定它们不能互换
Tooltip 必须绑定到一个 DOM 元素上，靠 mouseenter/
触发，移出或失焦即收起；它没有“主动显示”能力，也不能手动关闭——浏览器控制生命周期。
- 常见错误：
element.title 或第三方库直接调 <code>show()模拟 Tooltip，但键盘聚焦时没响应，不满足无障碍要求 - 正确做法：用
aria-describedby关联<div role="tooltip">，由焦点管理器自动控制显隐 <li>Toast 则完全相反：由 JS 主动调用 <code>showToast()或notify()触发，有固定持续时间（如 3s），可手动关闭，不依赖任何宿主元素 - 容易踩的坑：把 Tooltip 的容器写成
position: relative包裹在按钮里——箭头会偏移，且无法跟随滚动 - 性能影响：Tooltip 需要
ResizeObserver或scroll监听做避让；Toast 只需一次渲染，无重排开销 - 移动端注意：Tooltip 在触摸设备上默认不触发（无 hover），必须额外加
click或focus支持，而 Toast 天然适配所有输入方式 - 设计红线：在 Tooltip 里放「点击查看详情」——用户点完跳转，气泡却还悬在原处，视觉残留干扰大
- 兼容性提醒：部分旧版 iOS Safari 对
aria-live区域内的 Toast 朗读不及时，但 Tooltip 的aria-describedby支持稳定 - 可访问性区别：Tooltip 属于「补充说明」，屏幕阅读器只在聚焦锚点时读；Toast 属于「状态反馈」，需用
aria-live="polite"主动播报
DOM 结构和定位方式根本不同
Tooltip 的箭头必须指向锚点元素，因此它的 position 通常为 absolute 或 fixed，且需监听锚点位置变化做重定位；Toast 是全局层叠，一般固定在视口右下角，用 position: fixed + z-index 控制层级，不关心页面内其他元素位置。
文案长度和交互限制差异极大
Tooltip 文案建议 ≤4 行、每行 ≤20 字，且禁止放链接、按钮、图片；Toast 虽也强调简洁，但允许带一个操作按钮（如“撤销”），且可支持图标+多行文本（最多 2 行正文 + 1 行操作）。
