对 transform 移动高亮块更可靠，因浏览器可将其交由合成层处理，避免重排，性能优于 left 或 margin-left；需用 translateX 动态计算位置、加 translateZ(0) 兼容 Safari、慎用 will-change。
transition 为什么对 transform 移动高亮块更可靠
直接对 left 或 margin-left 做 transition，在分页器中容易卡顿或跳变，尤其页码频繁切换时。浏览器对 transform 的动画能走合成层（compositor layer），不触发重排（reflow），性能好得多。
实操建议：
- 高亮块用绝对定位，宽度固定，通过
transform: translateX()控制水平位置 - 不要用
left+transition: left 0.2s，哪怕看起来“更直观” - 确保父容器有
overflow: hidden，避免移动时溢出可见 - 初始状态要设
transform: translateX(0)，否则首次动画可能不触发
如何动态计算高亮块的 translateX 值
不能写死像素值——页码数量、按钮宽度、间距都可能变。核心是拿到当前页码按钮的 offsetLeft 和父容器滚动偏移（如果有）。
常见错误现象：transform 移动距离总是偏左/偏右几个像素，或在响应式下完全错位。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 监听页码点击后，用
getBoundingClientRect()拿当前按钮相对于分页器容器的位置 - 如果分页器支持横向滚动，记得减去容器的
scrollLeft - 别直接用
offsetLeft：它不含 margin，也不受transform影响，但会受父级border或padding干扰 - 示例关键逻辑：
const btn = document.querySelector('.pager-btn.active');<br>const rect = btn.getBoundingClientRect();<br>const container = document.querySelector('.pager');<br>const containerRect = container.getBoundingClientRect();<br>highlightEl.style.transform = `translateX(${rect.left - containerRect.left}px)`;
will-change: transform 该不该加
加了不一定更快，反而可能引发内存占用升高或渲染异常，尤其在低端安卓 WebView 中。
使用场景：仅当高亮块移动非常频繁（比如快速滑动页码条），且已确认 transform 动画掉帧时才考虑。
实操建议：
- 优先靠 CSS 层级优化：给高亮块加
contain: layout paint，减少样式影响范围 - 如果加
will-change，务必在动画结束后移除（用transitionend事件），否则持续占 GPU 资源 - 不要全局写在 CSS 里，例如
.highlight { will-change: transform; }—— 这会让浏览器一直维持合成层 - 现代 Chrome/Firefox 对简单
transform动画已自动优化，多数情况不需要手动干预
移动端 Safari 下 transform 动画突然失效
典型表现：点击页码，高亮块瞬间跳到目标位置，没有过渡动画。不是代码没写，而是 Safari 对某些组合属性“静默降级”。
根本原因：Safari 在非硬件加速上下文中会忽略 transition，尤其当父元素有 perspective、backface-visibility 或嵌套 transform 时。
实操建议：
- 给高亮块加
translateZ(0)或scale(1)强制开启硬件加速：transform: translateX(100px) translateZ(0) - 检查父容器是否设置了
overflow: scroll且同时用了-webkit-overflow-scrolling: touch—— 这个老属性会干扰合成层 - 避免在高亮块上同时设置
transform和filter（如drop-shadow），Safari 会退回到软件渲染 - 真机调试时打开 Safari 开发者工具 → “Timelines” 面板，看动画是否落在 “Composited Layers” 轨道里
CSS 动画看似简单，但分页器这种需要频繁重定位+响应式适配的场景，transform 的计算时机、硬件加速触发条件、浏览器兼容边界，每一步都容易漏掉一两个像素或一帧延迟。
