Tooltip 靠近屏幕边缘时自动调整位置，本质上就是在解决「定位参考失效 + 边界检测缺失」这两个核心问题。想让提示框在边缘区域自动避让，必须依赖 JS 动态计算视口坐标并实时修正位置，CSS 主要负责样式渲染与细节微调；另外，getBoundingClientRect() 需要结合 scrollX/Y 才能转换为文档坐标，而 confine:true 的含义是优先避免越界，并不是绝对不会超出边界。
Tooltip 靠近屏幕边缘时如何自动调整位置，核心仍然是处理「定位参考失效 + 边界检测缺失」这两个常见问题。仅靠纯 CSS 无法完成运行时的边界判断，因此必须借助 JS 获取视口坐标并动态修正 Tooltip 位置；CSS 负责展示效果和局部微调，但不能替代定位逻辑。
getBoundingClientRect() 是定位起点，但不是终点
很多开发者会直接通过 elem.getBoundingClientRect() 获取 left/top，然后把结果直接写入 tooltip 的 style.left/style.top，结果页面一滚动就发生偏移，窗口一缩放就出现错位。这是因为 getBoundingClientRect() 返回的是“相对于当前视口”的坐标，而 position: absolute 的 tooltip 默认往往是基于文档坐标系进行定位的。
- 必须叠加
window.scrollX和window.scrollY，才能换算出准确的文档坐标 - 如果 tooltip 的父级容器设置了
transform或perspective，就会生成新的包含块，这时通常需要结合getComputedStyle(parent).transform做额外补偿（虽然不常见，但确实容易踩坑） - 在移动端双指缩放场景下，
vw/vh单位可能发生跳变，Tooltip 定位偏差会更加明显——因此更建议使用px或em控制 tooltip 本身宽高和箭头尺寸
confine: true 不等于“不越界”，而是“优先不越界”
ECharts 的 confine: true 与 Bootstrap + Popper 的 flip: false 看起来像是在解决同一类 Tooltip 边界问题，但实际表现并不相同：前者主要限制 tooltip 内容尽量不要超出视口，不过箭头部分仍可能溢出；后者在关闭翻转后，甚至连主体内容都可能被直接裁切。更重要的是，它们通常都不会主动处理“触发元素本身已经贴近边缘”的情况。
confine: true在 ECharts 中通常需要配合appendToBody: true使用才更稳定，否则依然可能被父容器的overflow:hidden截断- Bootstrap Tooltip 默认会启用
flip，如果手动关闭它（flip: false），同时又强制设置placement: 'top'，当按钮紧贴顶部时，tooltip 就会直接向上超出屏幕——这并不是组件 bug，而是关闭了它的兜底保护机制 - 真正稳定可靠的 Tooltip 自动避让方案，通常还是要自己补充边界校验逻辑：例如先计算 tooltip 高度，再判断
triggerRect.top - tooltipHeight < 0，若条件成立就切换到底部显示
伪元素箭头 + 绝对定位的响应式陷阱
很多人会使用 ::after 绘制箭头，再配合 left: 50% + transform: translateX(-50%) 实现居中，这种写法看似简单，但在响应式页面或复杂布局中很容易出现定位不准的问题。
- 如果触发元素没有设置
position: relative，tooltip 可能会一路向上追溯到body进行定位，页面一滚动就容易发生偏移 - 如果在媒体查询中把触发元素改成
display: none，那么 tooltip 的定位上下文也会随之消失，下次再次显示时坐标往往会全部错乱 - 箭头若通过
border绘制，而border-width又是固定像素值，大屏设备上会显得偏小，小屏设备上又可能撑开容器——更建议统一改用clip-path或 SVG 内联图标来实现箭头效果
还有一个非常容易被忽略的关键点，就是 tooltip 的显示时机。相比在 mouseenter 触发后立刻计算位置，更推荐使用 requestAnimationFrame 延迟到下一帧再执行——尤其是在页面刚加载完成，或者 DOM 正在批量插入、布局尚未稳定时，过早调用 getBoundingClientRect() 很可能拿到错误尺寸，进而导致 Tooltip 自动定位失效或边缘判断不准确。
