用 transform: translateX() + getBoundingClientRect() 配合 requestAnimationFrame 是唯一稳定方案；left/width 动画因触发重排、参照系错乱、测量漂移等问题在 iOS Safari 和低端 Android 上易卡顿跳变。
直接用 transform: translateX() + getBoundingClientRect() 动态计算位置，配合 requestAnimationFrame 更新，是唯一能稳定跑顺的方案。用 left 或 width 做动画，在 iOS Safari 和低端 Android 上大概率卡顿、跳变、甚至闪回初始位置。
为什么 left / width 动画在 Tab 切换里不可靠
它们触发重排（reflow），浏览器必须重新计算整个布局树——尤其当 Tab 文字长度不一、父容器是 flex、页面缩放或字体动态变化时，offsetLeft 和 offsetWidth 返回值极易漂移。更糟的是，transition: left 0.3s 在快速连续点击时掉帧严重，下划线会“抢跑”或残留。
-
left依赖 offsetParent，而 flex 容器、padding、transform 缩放都会让参照系错乱 -
width在 inline 元素上可能被忽略，且受系统字号放大影响，测量结果不可靠 - 伪元素（如
::after）若没包裹在position: relative的同级容器里，left值直接飘出视口
下划线 DOM 结构和 CSS 必须怎么写
下划线元素必须和 Tab 项同级，并共用同一个 position: relative 父容器，否则 translateX() 的参照系是 body 或滚动祖先，一动就偏移。
- HTML 示例：
<div class="tab-nav"><button>首页</button><button>发现</button><div class="underline"></div></div> -
.tab-nav必须设position: relative，否则.underline的translateX()会相对 body 移动 -
.underline初始状态要显式写transform: translateX(0) scaleX(0)，不能只靠 transition 触发 - 别同时写
left: 0和transform: translateX(0)，CSS 层叠会让后者覆盖前者，但 JS 计算逻辑若还依赖left就会混乱
JS 怎么算出准确的 translateX 和 width
用 offsetLeft 看似简单，但在 flex、文字换行、缩放页面下极不可靠。真正稳的解法是统一用视口坐标做减法：
立即学习“前端免费学习笔记（深入）”；
- 获取目标 Tab 元素：
const targetRect = tabEl.getBoundingClientRect() - 获取导航容器：
const containerRect = navEl.getBoundingClientRect() - 计算位移：
const x = targetRect.left - containerRect.left + targetRect.width / 2 - underlineWidth / 2（居中对齐时） - 宽度直接取
Math.round(targetRect.width)，防止 sub-pixel 渲染抖动 - 所有样式更新必须包在
requestAnimationFrame()里，避免强制同步布局
transition 失效的三个高频坑
写了 transition: transform 0.3s ease 却没动画？大概率掉进了下面这些坑：
- 下划线元素没加
position: absolute，或父容器没设position: relative，导致transform作用域错误 -
transition写在:hover或.active态上，而不是默认态——动画必须定义在“静止状态”，否则首次触发无过渡 - DOM 更新后没等重排完成就立刻读尺寸，比如 Vue/React 中未用
nextTick或requestAnimationFrame包裹读取逻辑
最复杂也最容易被忽略的点是：滑块位置不是“点一下更新一次”就够。窗口 resize、横竖屏切换、字体加载完成、甚至权限控制导致 Tab 动态增删，都可能改变布局尺寸，必须监听并重算——否则第一次看着对，第二次就偏了。
