移动端必须用transform: translate()而非left/top，因后者在ios safari和android chrome中每帧触发1–3ms layout，而前者仅走gpu合成层，避免重排、保障60fps；需归零定位、慎用will-change并处理亚像素抖动与点击错位。
移动端平移动画必须用 transform: translate()，不能依赖 left/top 或 margin —— 否则容易卡顿、掉帧，甚至触控响应延迟。
为什么移动端必须用 translate 而不是 left/top？
在 iOS Safari 和 Android Chrome 上，left/top 触发 layout（重排），而移动端 CPU 性能弱、渲染管线更敏感，一帧卡顿就明显。translate() 只走合成层（composite），由 GPU 处理，不阻塞主线程。
- 实测：相同动画下，
left在低端安卓机上帧率常跌破 30fps；translateX()稳定 60fps -
position: fixed元素若用top动画，还会触发 viewport 重计算，导致页面“抖动” - iOS Safari 对
will-change: transform支持有限，但translate3d(0,0,0)仍可强制启用合成层
transition 触发平移时，hover 不生效怎么办？
移动端没有 hover，靠伪类模拟会失效。必须改用 class 切换或 JavaScript 控制状态。
- 错误写法：
.box:hover { transform: translateX(20px); }—— 在手机上几乎不触发 - 正确做法：用 JS 添加类，例如
element.classList.add('moved')，CSS 定义.box.moved { transform: translateX(20px); } - 避免直接操作
style.transform，否则可能绕过 transition（尤其在快速连续操作时） - 如果用 React/Vue，确保 class 切换不被 batch update 合并，必要时加
setTimeout(() => ..., 0)强制下一帧生效
animation 实现循环浮动时，如何避免 iOS Safari 卡顿？
iOS Safari 对 @keyframes 中频繁修改 transform 的优化不如 Chrome，需手动干预合成策略。
- 必须加
transform: translateZ(0)或translate3d(0,0,0)到动画元素上，强制创建独立图层 - 避免在
@keyframes中混用opacity和transform—— iOS 旧版会降级到软件合成 - 动画时长建议 ≥ 300ms，太短（如 100ms）在 60Hz 屏幕上易因舍入误差跳帧
- 慎用
animation-timing-function: cubic-bezier(...)，部分 iOS 版本对自定义贝塞尔支持不稳定，优先用ease-in-out
touchmove 场景下做跟随位移，怎么保证流畅？
手指拖拽时实时更新位置，不能用 transform 频繁写 style，否则主线程忙不过来。
- 用
requestAnimationFrame批量更新，不要在touchmove里直接设element.style.transform - 优先用 CSS 自定义属性 +
calc()配合transform: translate(var(--tx), var(--ty))，再由 JS 更新--tx/--ty—— 更轻量 - 对高频位移元素加
will-change: transform，但仅限动画开始前设置，动画结束后及时移除（否则长期占用内存） - 真机测试时关掉“缩放辅助”和“粗体文本”等系统级可访问性设置，它们会干扰合成层行为
最易被忽略的一点：移动端动画的“平滑”不只取决于 CSS 写法，更取决于是否让浏览器提前知道“这个元素要动”。transform 是钥匙，但得配合图层策略、事件节流和真机验证，缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
