滑块位置不准的根本原因是left/width依赖文档流计算，而flex布局、文字换行、缩放或滚动会导致offsetLeft漂移；必须用getBoundingClientRect()获取视觉坐标并减去父容器偏移，且需在DOM更新、resize、字体加载完成等时机动态重算，配合transform: translateX()实现平滑移动。
滑块为什么总对不准位置
根本原因不是样式写错了，而是用了 left 和 width 直接赋值——它们依赖文档流计算，在 flex 布局、文字换行、缩放或滚动后，offsetLeft 会漂移，getBoundingClientRect() 又没减去父容器偏移。结果就是滑块悬空、偏左/偏右、宽度忽大忽小。
- 必须用
getBoundingClientRect()获取视觉坐标，再减去导航容器的left值，转成相对定位 - 不能只在页面加载时算一次，点击切换、窗口 resize、甚至字体加载完成都可能改变尺寸，得重新触发
- 如果导航容器有
padding或transform，offsetParent的参照系就不可靠，offsetLeft必然出错
怎么用 transform 替代 left 实现平滑移动
改用 transform: translateX() 不仅避免重排，还能走 GPU 合成层。但关键不是“加了 transform 就行”，而是位移值必须基于容器内坐标系计算，且要居中对齐或适配滑块自身宽度。
- 滑块元素需和导航项同级，并包裹在同一
position: relative容器下，否则translateX()会相对 body 移动 - 位移值 =
targetRect.left - containerRect.left + targetRect.width / 2（居中对齐时），若滑块宽 48px，还得额外减去 24px 补偿 - 务必在
requestAnimationFrame中更新style.transform，否则浏览器可能强制同步布局，导致卡顿 - 别同时设置
left和transform—— 浏览器会合并计算，首次动画常跳变
哪些时机必须重新计算滑块位置
不是“点一下更新一次”就够。DOM 渲染是异步的，很多变化不会立刻反映到尺寸上，比如 Vue 的响应式更新、React 的 state 提交、甚至字体加载完成都会影响布局。
-
DOMContentLoaded后初始化一次 - 每次点击切换 tab 后，先确保
.active类已生效（用requestAnimationFrame或nextTick等待重排完成），再读取新元素位置 - 监听
resize和orientationchange，横竖屏切换时容器宽度突变，不重算就会错位 - 如果导航项支持动态增删（如权限控制隐藏某 tab），需在 DOM 变更后手动触发重算
伪元素 ::after 方案的常见陷阱
用 ::after 实现下划线看似简洁，但容易因定位上下文缺失直接失效。它不像独立 div 那样能自由设 style，所有逻辑都压在 CSS 层，JS 控制力弱。
立即学习“前端免费学习笔记（深入）”；
-
li必须显式设position: relative，不能只给ul设——否则所有::after都锚定到同一个祖先上 -
::after要设position: absolute; bottom: 0;，且width和transform: translateX()必须由 JS 动态注入，不能靠 CSS 变量硬编码 - 首次渲染前，若 tab 元素尚未完成字体度量（font loading），
getBoundingClientRect().width可能为 0，得等document.fonts.load或延迟触发 - 移动端 Safari 对
will-change: transform更敏感，建议加上，但别滥用——只对滑块元素设
真实场景里，最易被忽略的是「首次渲染时机」：DOM 挂载了，但字体还没加载完，文字宽度没定型，getBoundingClientRect() 就取到了错误值。这时候光靠 resize 或 click 监听救不了，得配合 fontload 或至少用 setTimeout 延迟一小会儿再初始化。
