下划线动画用 transform: translateX() 而非 left 是因后者触发重排，前者仅重绘或合成，更顺滑；需绝对定位、JS 动态设宽、避免 width 过渡，并注意 Safari 兼容性与动画队列清理。
下划线跟随动画为什么用 transform: translateX() 而不是 left
因为 left 触发重排（reflow），而 translateX() 只触发重绘（repaint）甚至合成（composite），动画更顺滑，尤其在中低端设备上差异明显。用 left + transition 在快速切换菜单项时容易卡顿、跳帧。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 下划线元素必须是绝对定位（
position: absolute），且父容器设为position: relative - 初始
transform: translateX(-100%)配合width: 0，避免首次渲染出现“闪现” - 不要对
width做过渡——它会触发重排；宽度靠 JS 动态设置，只过渡transform
如何用 JS 精确计算目标菜单项的下划线位置
不能直接读 offsetLeft 或 getBoundingClientRect().left，因为导航条可能有 padding、flex gap、文字缩放或字体加载延迟，导致位置偏移。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
targetElement.getBoundingClientRect()获取相对于视口的位置，再减去导航容器的getBoundingClientRect().left - 如果导航是 flex 布局，确保容器没设
justify-content: center等居中属性干扰计算，否则需额外加偏移补偿 - 监听
resize和fontload（可用document.fonts.load()）后重新校准一次位置 - 示例关键计算：
const navRect = navEl.getBoundingClientRect(); const itemRect = targetItem.getBoundingClientRect(); const x = itemRect.left - navRect.left + itemRect.width / 2 - underlineWidth / 2;
hover 和点击切换时下划线“抢跑”或“滞后”的原因
本质是过渡状态未同步：JS 设置了新位置，但 CSS 过渡还没从旧状态“松手”，或多个事件（如 mouseenter + click）触发了冲突的动画队列。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 每次移动前先清除正在运行的 transition：
underlineEl.style.transition = 'none'，再设新transform，然后void underlineEl.offsetWidth强制重排，最后恢复 transition - 对
click切换主动调用element.focus()，避免键盘用户操作时下划线不响应 - 禁用移动端双击缩放干扰：
touch-action: manipulation加在导航容器上
兼容性陷阱：Safari 下 transform: translateX() 动画卡顿或失效
Safari（尤其 iOS 15–16）对 transform 的硬件加速判断更苛刻，单纯 translateX 有时不会进合成层。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 强制开启 GPU 加速：
transform: translateX(0) translateZ(0)，注意translateZ(0)不能省略 - 避免在
:hover里直接写transform过渡——Safari 对伪类中动态 transform 支持不稳定，统一由 JS 控制 - 如果用了
will-change: transform，务必在动画结束后移除，否则内存占用持续升高
下划线动画看着简单，真正跑得稳的关键不在“怎么动”，而在“什么时候动、动之前清不清场、动完有没有收尾”。特别是 resize 后没重算位置、Safari 里忘了 translateZ(0)、或者多个事件同时触发却没 cancel 上一个动画——这些点一漏，用户看到的就是一顿一顿的线条。
