transform + transition 能跑满60fps，因为浏览器对transform和opacity的变更天然走合成层（compositor thread），不触发Layout和Paint，仅执行Composite；而left、top等属性会强制触发Layout→Paint→Composite全流程，导致主线程卡顿、帧率骤降。
为什么 transform + transition 能跑满 60fps
因为浏览器对 transform 和 opacity 的变化天然走合成层（compositor thread），不触发重排（Layout）和重绘（Paint），只做图层合成（Composite）。而改 left、top、width 等属性，会强制走 Layout → Paint → Composite 全流程，主线程一卡，帧率立刻掉到 30fps 甚至更低。
- GPU 加速只对
transform（含translateX、scale、rotate）和opacity有效；其他属性再怎么加will-change也白搭 - 现代浏览器中，
transform: translateZ(0)或translate3d(0, 0, 0)已非必需，但在老版 Safari/Android Webview 里仍能兜底强制升层 - 哪怕只是多写一个
margin: 0在动画元素上，如果它被 JS 动态修改，也可能意外触发 Layout —— 所以要盯紧“谁在动”
transition 必须写在目标元素上，且不能省略单位
很多人把 transition 写在触发器（比如按钮）上，结果动画根本不执行。真正要动的元素（比如弹出的菜单、滑入的卡片），它的 CSS 里必须提前声明 transition，并且明确指定属性名和时间单位。
- ✅ 正确：
transition: transform 0.3s ease, opacity 0.3s ease - ❌ 无效：
transition: 0.3s（缺属性名和单位） - ❌ 危险：
transition: all 0.3s（可能把color、background也拉进过渡，干扰 JS 切换 class） -
transform: translateX(50)是非法值 —— 缺单位（如px、rem），浏览器直接忽略，导致过渡“没反应”
JS 读取 offsetTop 等属性会打断 transition
即使你用对了 transform 和 transition，只要在动画进行中调用了 offsetLeft、getBoundingClientRect()、scrollHeight 这类同步 Layout API，浏览器就会立刻 flush style → layout → paint，动画当场跳变或闪一下。
- 常见场景：hover 后立即读取
el.offsetHeight做后续计算 - 修复方式：用
requestAnimationFrame延迟到下一帧再读，或改用 CSS 自定义属性 +calc()避开 DOM 查询 - 动画开始前加
will-change: transform，结束后及时移除（比如监听transitionend事件）；长期挂着会吃 GPU 内存
缓动函数和初始值漏设，也会让动画“不顺”
看起来是性能问题，其实可能是视觉断层。比如没设初始 transform: translateX(0)，直接在 hover 里写 translateX(100px)，浏览器找不到起始状态，第一帧就跳过去。
立即学习“前端免费学习笔记（深入）”；
- 务必为所有参与 transition 的
transform属性设初始值（哪怕就是none或translateX(0)） -
cubic-bezier(0.25, 0.46, 0.45, 0.94)比ease-in-out更自然，适合入场；cubic-bezier(0.6, 0.05, 0.28, 0.69)带回弹感，适合退出 - 移动端要注意
touch-action: manipulation，否则手指松开后动画可能延迟一帧才启动
