HTML气泡仅是视觉容器，不自带消息逻辑；需JS控制显隐、内容与时机才能形成提示语义；真正消息系统需统一ID管理、事件分发及生命周期控制。
HTML气泡不依赖消息提示系统
纯 HTML + CSS 实现的气泡（比如 tooltip 或聊天气泡）本身和“消息提示”功能无绑定关系。它只是视觉容器，不自带通知逻辑、状态管理或事件分发。所谓“提示”，是开发者用 JS 控制显隐、内容、触发时机后才形成的语义。
-
title属性能自动出气泡，但不可定制样式、无法加交互、移动端基本失效 - 用
:hover或:focus触发的纯 CSS 气泡，没有 JS 也能工作，但仅限简单场景 - 一旦需要点击展开、延时关闭、位置避让、键盘可访问，就必须靠 JS 补足，此时才可能和消息队列、状态通知等机制耦合
气泡显示逻辑常被误当成消息系统
很多项目把 showTooltip() 封装成全局函数，再配个 toast.show("保存成功")，就以为自己搭了“消息提示系统”。其实这只是调用入口统一，底层仍是零散 DOM 操作。
- 没做生命周期管理：重复调用
showTooltip()可能残留多个气泡节点，尤其在快速连续触发时 - 没处理焦点/键盘：屏幕阅读器无法感知，
Esc关不掉，Tab跳过气泡内容 - 没隔离作用域：一个组件里
document.querySelector(".tooltip")可能选中其他模块的气泡，造成误操作
真正需要消息提示时，气泡只是渲染层
当业务要求“所有错误统一右上角弹出”“操作成功后3秒自动消失”“支持手动关闭+重试按钮”，这时候气泡退化为 UI 组件，背后得有消息中心支撑。
- 消息应有唯一
id，用于去重、更新、清除；不能只靠 class 名控制显隐 - 推荐用事件总线或 Context API 分发，而不是直接调用 DOM 方法，否则测试难、复用差
- 气泡组件接收
{ id, content, type, duration }等标准化字段，内部决定用什么样式渲染——可能是带叉号的div，也可能是dialog元素
移动端 Safari 的气泡定位是个硬伤
用 position: absolute 配合 getBoundingClientRect() 算位置，在 iOS Safari 上极易偏移，尤其页面有缩放、输入法弹起、地址栏收放时。
- 避免依赖
window.scrollY计算，改用element.getClientRects()[0]获取当前视口坐标 - 不要在
resize或orientationchange里立刻重算，加requestAnimationFrame节流 - 若气泡需跟随滚动元素（如表格行内操作），优先用
position: fixed+ 动态top/left，而非absolute相对定位
气泡最容易被忽略的不是样式，而是它何时该消失——没人点、没设定时器、没监听 focusout 或 blur，它就会一直挂着，既挡操作又误导用户。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
