应使用 transform: translateX() + transition: transform 实现下划线动画，避免 left 或 width 触发重排；需设 overflow: hidden 防溢出；JS 计算坐标应基于 getBoundingClientRect()，更新样式须用 requestAnimationFrame；transition 必须写在常态 class 中，移动端需用 pointerdown 替代 hover，will-change 应动态添加并及时清除。
直接上结论：用 transform: translateX() + transition: transform，别碰 left 或 width 动画。卡顿根源不是写法“不对”，而是触发了重排（reflow）——浏览器得重新计算整个布局。
为什么用 translateX() 而不是 left
给下划线设 position: absolute 后改 left，每次切换都要触发重排；而 transform 只走合成层（compositor），靠 GPU 加速，滚动、快速悬停、频繁切换都不掉帧。
常见错误是：伪元素写 left: 0; transition: left 0.3s，结果在 Chrome DevTools 的 Rendering 面板里能看到 Layout forced 标记，动画一卡一卡的。
必须确保下划线容器（比如 .nav）设 overflow: hidden，否则 translateX() 移出范围时可能露边。
怎么让下划线精准对齐目标菜单项
纯 CSS 方案（无 JS）只能靠 :has() 或 nth-child 手动写死每个位置，不推荐用于动态菜单。
真实项目几乎都用 JS 控制，关键不是“怎么算”，而是“用什么坐标”：
• 别用 offsetLeft —— 它依赖 offsetParent，而 flex/grid 布局下可能指向 body，值不可靠
• 正确做法是：用 target.getBoundingClientRect().left - container.getBoundingClientRect().left 得到相对父容器的左偏移
• 宽度用 target.offsetWidth 或 target.getBoundingClientRect().width
• 更新样式务必包在 requestAnimationFrame 里，避免强制同步布局
• 首次加载要初始化：默认对齐第一个菜单项，transform: translateX(0) + width 设为它的宽度
transition 写在哪？为什么不能只写在 active 类里
必须写在下划线元素的常态 class 里，比如：.nav-underline { transition: transform 0.3s ease-out, width 0.3s ease-out; }
而不是只在 .nav-underline.active 里声明。
原因有两个：
• 如果只在 active 里写，首次添加 class 时没有过渡效果（transition 属性本身需要从无到有生效）
• 更隐蔽的问题是：如果用 CSS-in-JS 或 Tailwind，运行时拼字符串加 transition，很可能漏掉或覆盖，导致动画失效
缓动函数用 ease-out 比 ease 更利落，收尾不拖尾；时间 0.3s 是实测平衡点，短了感觉突兀，长了响应迟滞
移动端和性能容易被忽略的细节
移动端没有 :hover，所以纯 CSS 的 hover 方案在真机上基本失效——必须用 pointerdown 或点击事件驱动 class 切换。
另一个常被忽略的坑是 will-change: transform：
• 动画开始前加它能提前提示浏览器启用合成层
• 但加完不清理，GPU 内存会持续占用，单页应用切十几次导航后内存悄悄涨
• 正确做法：JS 添加 class 触发动画前设 style.willChange = 'transform'，动画结束 50ms 后用 setTimeout(() => { el.style.willChange = 'auto' }, 50) 清掉
• 别在 CSS 里全局写 will-change: transform，那等于长期驻留
