根本原因是 Popper.js 通过 getBoundingClientRect() 获取缩放元素位置时，该方法返回的是未变换的逻辑边界，导致气泡框锚点错位；正确解法是将 transform 移至父容器或用 font-size/padding 替代缩放。
根本原因是 Popper.js 读取 getBoundingClientRect() 时，缩放（transform: scale()）改变了元素的视觉尺寸和坐标系，但 DOM 布局盒模型未变，Popper 拿到的是缩放前的逻辑边界，导致气泡框锚点错位。
缩放元素本身是定位失效的直接诱因
Bootstrap 的 Tooltip、Popover 等浮层组件底层依赖 Popper.js，而 Popper 默认通过 getBoundingClientRect() 获取触发元素的宽高和位置。该方法返回的矩形始终基于原始未变换的盒模型——哪怕你写了 transform: scale(1.2)，它返回的 width 和 top/left 仍是缩放前的值。
结果就是：气泡框按“原大小按钮”的左上角定位，但视觉上按钮已放大，看起来就像气泡飘在按钮左上方或偏右下方。
- 用浏览器开发者工具选中触发元素，在 Console 执行
document.querySelector('.your-trigger').getBoundingClientRect()，对比缩放前后输出，能直观看到数值没变 -
transform: scale()和rotate()一样，属于“不影响文档流但干扰几何计算”的变换，不能靠top/left补偿 - 加
data-bs-offset或自定义offset配置只能微调，无法根治——因为 offset 是叠加在错误基准上的偏移
正确解法是隔离缩放影响范围
不让 Popper 的锚点计算接触到缩放样式，是最稳定的做法。有两条路径可选：
- 把
transform: scale()移到触发器的父容器上，例如：，然后只对.scaled-wrapper应用缩放 - 若必须缩放按钮本身，改用
font-size+padding模拟视觉放大（适用于文字类触发器），或用 SVG 图标替代缩放，彻底避开 transform 干扰 - 极端情况可手动刷新 Popper 实例：
Tooltip.getInstance(element).update()，但需包裹在requestAnimationFrame中，否则仍读到旧尺寸
导航栏/固定定位场景下更易出问题
Navbar 内部是 flex 布局，transform 会破坏 .nav-item 的对齐基准；而 position: fixed 元素（如顶部导航栏）叠加缩放后，Popper 计算的视口边界也会失准。
- 检查是否给
.nav-link或其祖先加了transform—— 即使只是scale(0.95)用于抗锯齿，也会触发错位 - 避免在
.tooltip触发器上同时使用transform和position: relative，后者会干扰 Popper 的offsetParent查找逻辑 - 第三方图标库（如 Font Awesome 的
fa-lg、fa-2x）内部可能注入transform，务必查 computed styles，不能只看 HTML class
最容易被忽略的是：缩放常和 will-change: transform 一起出现，后者会强制创建新图层，进一步加剧 Popper 对布局边界的误判。真要优化性能，优先考虑用 scaleZ(1) 或 CSS 变量控制尺寸，而不是无差别加 transform。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
