用 transform: translatex() + transition 实现导航栏下划线动画最顺滑；需配合 offsetleft/offsetwidth 动态计算位置、监听 resize、使用 pointerdown 事件并避免 will-change 长期驻留。
导航栏下划线怎么让 transform 动起来不卡顿
直接上结论：用 transform: translateX() + transition，别用 left 或 width 动画。浏览器对 transform 的硬件加速支持更稳，尤其在滚动或频繁切换时不会掉帧。
常见错误是给下划线元素设 position: absolute 后用 left 跟随菜单项位置——每次切换都要重排版（reflow），动画一卡一卡的；换成 transform 就只触发重绘（repaint），顺滑得多。
- 下划线容器必须设
overflow: hidden，否则translateX移出范围时可能露边 - 过渡时间建议
transition: transform 0.3s ease-out，ease-out比ease更利落，避免拖尾感 - 别在
:hover里写transform，要用 js 控制 class 切换，否则移动端点不到、伪类失效
JS 怎么精准算出目标菜单项的 offsetLeft 和 offsetWidth
不是所有菜单项宽度一致，也不能靠 getBoundingClientRect() 算完就扔——它返回的是视口坐标，而 transform 需要相对父容器的偏移量。
正确做法是把下划线元素放在导航栏内部、和菜单同级，用 offsetLeft 和 offsetWidth 获取目标项相对于父容器左边缘的距离和自身宽，再赋给下划线的 transform 和 width。
立即学习“前端免费学习笔记（深入）”；
- 记得监听
resize，窗口缩放后菜单位置会变，得重新计算 - 如果菜单用了
flex布局，offsetLeft依然可靠；但用了grid且有justify-content: center，就得先取父容器getBoundingClientRect().left做校准 - 首次加载时，下划线默认对齐第一个菜单项，别漏掉初始化逻辑
为什么 transition 写在下划线元素上而不是父容器
因为动画主体是下划线本身的位置和尺寸变化，不是整个导航栏。写在父容器上会导致所有子元素都参与过渡，干扰菜单文字 hover 效果，甚至引发意外交互延迟。
另一个坑是加了 will-change: transform 却没清理——长期驻留会持续占用 GPU 内存，尤其在单页应用里切多次导航后内存悄悄涨。
-
transition必须写在下划线元素的常态 class 里（比如.nav-underline），不能只写在 active 状态里 - 如果用 css-in-JS 或 Tailwind，确保
transition是静态声明，不是运行时拼字符串塞进去的 - 真要优化性能，可在动画开始前加
will-change: transform，结束 50ms 后用 JS 移除
移动端点击后下划线不动？检查 touchstart 和 click 冲突
PC 上靠 mouseenter / mouseleave 触发没问题，但移动端 touch 事件会先触发 touchstart，紧接着冒泡出 click，导致 JS 还没来得及更新下划线位置，class 就被覆盖了。
简单解法是统一用 click，并加 preventDefault() 在 touchstart 上防滚动干扰；更稳妥的是监听 pointerdown，它自动兼容 mouse/touch/pen。
- 别依赖
:active伪类驱动下划线，它只在按住瞬间生效，松手就没了 - 如果菜单用了
router-link（Vue）或Link（React），确保事件绑定在包裹元素上，而不是a标签内部 - 测试时真机连 devtools，用
console.log打点看事件触发顺序，比模拟器靠谱
事情说清了就结束。最常被忽略的是 resize 重算和 pointer 事件兼容性——这两个点不处理，上线后一半用户会觉得“有时候动不了”。