低端安卓机用top/left动画会跌破20fps，因强制重排；应改用transform: translateX/Y并按需设置will-change，避免同步读取布局信息。
低端安卓机（尤其是 Android 5–7 WebView）上，用 top 或 left 做位移动画，基本等于主动放弃 60fps。这不是“不够顺滑”，而是帧率会掉到 20fps 以下，手指一滑就粘滞——根本原因不是 CPU 慢，是浏览器被逼着每帧都重排。
为什么 top/left 一动就卡死
改 top 或 left 会强制触发重排（reflow）：浏览器得重新计算该元素及其后代的位置、尺寸、换行、甚至整行文本的布局。这个过程在主线程串行执行，低端机调度弱，一帧内卡住多次，动画就断成幻灯片。
transform: translateX() 则完全不同：它不改文档流，只告诉合成器“把这张图层往右挪 100px”，GPU 直接处理，跳过 layout 和 paint 阶段。
- 错误写法：
transition: left 0.3s→ 整条动画降级为 CPU 渲染 - 正确写法：
transition: transform 0.3s→ 保持合成线程运行 - 哪怕只是临时调试加了
left: 0，只要它和transform同时存在，浏览器就会放弃硬件加速
如何安全替换 top/left 动画
不能只改属性名，得同步调整定位逻辑。常见场景要逐个处理：
- 绝对定位居中？别用
top: 50%; margin-top: -XXpx，改用transform: translateY(-50%) - 侧滑菜单？
left: -100%改成transform: translateX(-100%)，同时确保父容器没设overflow: hidden（某些安卓 WebView 下会破坏合成） - 下拉刷新 header 抖动？不是靠
top拉动，而是给 header 加transform: translateY(XXpx)，并用will-change: transform动态控制 - 滚动锚点平滑跳转？JS 中不要读
el.offsetTop后再设top，改用el.scrollIntoView({ behavior: 'smooth' })或手动计算后只写transform
translateX/Y 之外的陷阱
不是所有 transform 都安全。移动端尤其要注意这些细节：
-
translate3d(0, 0, 0)曾是“骗硬件加速”的惯用写法，但现在不推荐：比translateY(0)多一次矩阵运算，在 iOS 15.4+ 反而可能引发图层合并开销 -
rotateX()或rotateY()在部分安卓 WebView 中会降级为软件渲染，优先用rotateZ() -
opacity: inherit或opacity: unset会直接让元素退出合成层，必须用确定数值如opacity: 0.99 - 动画中混用
transform: scale()和box-shadow？后者会破坏图层合并，导致频繁重绘
will-change 不是开关，是定时器
静态写 will-change: transform 在 CSS 里，等于让每个元素常驻 GPU 图层——低端机内存吃紧时直接 OOM 卡死。
真正有效的做法是“按需升层”：
- 动画开始前 1–2 帧（比如
touchstart时）用 JS 设置：el.style.willChange = 'transform' - 监听
animationend或transitionend后立刻清空：el.style.willChange = 'auto' - iOS Safari 对 ≤16ms 的动画可能不触发
animationend，加兜底：setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要写
.list-item { will-change: transform; }—— 列表滚动时批量建层，就是等着卡住
最常被忽略的掉帧元凶，不是没加 will-change，而是在动画过程中偷偷读取 getBoundingClientRect() 或 getComputedStyle(el)。这类操作会强制同步触发布局，一帧内反复读写，帧率就崩了。读取必须前置，写入必须后置，中间不能穿插。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
