根本原因是用left或width动画触发重排，导致卡顿错位；应改用transform: translatex()+transition，并配合getboundingclientrect()动态计算位置与requestanimationframe更新。
移动端 Tab 切换时下划线卡顿、跳变、错位，根本原因不是 CSS 写得不够“炫”，而是用了 left 或 width 做动画，触发了重排（reflow）——尤其在 iOS Safari 和低端 Android 上，一卡一个准。真正能跑顺的方案，只有一条路：用 transform: translateX() + transition: transform，再配 JS 动态读取位置。
为什么不能直接用 left / width 做动画？
浏览器对 left、width 的修改必须重新计算布局（reflow），而移动端屏幕尺寸多变、字体渲染差异大、flex 容器缩放频繁，每次切换都可能让 offsetLeft 失准；更糟的是，transition: left 0.3s 在滚动中或快速连续点击时极易掉帧，甚至出现“闪回”到初始位置的现象。
-
left动画依赖文档流位置，但 Tab 文字长度不一、响应式缩放后，父容器宽度变了，left值就失效 -
width动画会强制浏览器测量元素内容，尤其在font-size动态变化（如系统字号放大）时，计算结果不可靠 - 伪元素（如
::after）用left定位时，若父容器没设position: relative，参照系错乱，下划线直接飘出视口
下划线元素必须怎么写才不会错位？
关键不在“怎么动”，而在“在哪动”——下划线必须和 Tab 项同级、包裹在同一 position: relative 容器里，且自身设 position: absolute。否则 translateX() 的参照系是视口或最近定位祖先，一滚动就偏移。
- 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)，不能只靠 transition 触发——否则首次加载可能不动画 - 别同时写
left: 0和transform: translateX(...)，CSS 层叠会让后者覆盖前者，但 JS 计算逻辑若还依赖left就会混乱
JS 怎么算出准确的 translateX 值？
用 offsetLeft 看似简单，但在 flex 布局、文字换行、缩放页面下极不可靠；真正稳的解法是用 getBoundingClientRect() 获取视觉坐标，再减去容器左边界。
- 正确做法：
const targetRect = tabEl.getBoundingClientRect(); const containerRect = navEl.getBoundingClientRect(); const x = targetRect.left - containerRect.left; - 务必在
requestAnimationFrame里更新transform，避免强制同步布局（forced reflow） - 监听
resize和orientationchange，窗口大小一变就得重算——否则横竖屏切换后下划线悬空 - 首次加载时，需手动初始化下划线位置，比如对第一个 Tab 调用一次计算逻辑，否则页面打开瞬间下划线在原点不动
最易被忽略的点：下划线元素的 width 也得动态设，不能写死。它必须等于目标 Tab 的 offsetWidth 或 getBoundingClientRect().width，否则在文字长短不一的 Tab 上，下划线会短一截或撑出边界。这个宽度值同样要在 requestAnimationFrame 中同步设置，和 translateX 保持原子性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
