transform: translateX(100%) → 0抽屉本来就占好位置，只是平移图层；主线程忙也顺。
动效 · 克制与性能
动效性能Motion Performance
动画是否流畅取决于每帧要做多少工作：只动 transform 和 opacity，并在降速和真机条件下验收。
先在“手机”上跑一次，看谁先卡
两条跑道上的卡片走同样的路线，区别只是动画改的是哪个属性。切换设备负载、换属性，看卡片本身和下面的帧条怎么变。
性能对照台
两条跑道上，同一张商品卡做同样距离、同样时长的来回移动，只是 AI 用了不同的属性。先在空闲状态下看，再切到“中低端手机”。
跑道 A
布局绘制合成每帧重新算位置，周围元素都要重排
点「播放对比」后看这张卡怎么动
跑道 B
布局绘制合成交给合成线程，主线程忙也不排队
点「播放对比」后看这张卡怎么动
主线程帧条等待播放
left / width 动画要靠这条主线程一帧一帧算；transform / opacity 的动画由合成线程驱动，不在这条队里排。第一步：保持“空闲”播放一次，两条跑道看起来一样顺。
从刚才的操作里提炼
- 卡不卡取决于“每帧要做几步”：改 left、width、top、margin，浏览器每帧都要重新布局、绘制、合成；改 transform、opacity 只要合成。
- transform / opacity 可以绕开忙碌的主线程：演示里主线程被占满时，它们的卡片照样顺，因为驱动它们的是合成线程。
- 电脑上验不出来：空闲时两条跑道一样顺。性能问题在中低端手机、页面还在加载脚本时才暴露。
- 掉帧看帧条：一帧超过约 17ms 就赶不上 60fps，超过 50ms 的长帧会让人明显觉得“一顿”。
- 动得少也是优化：同时在动的东西越少越好，减少动效模式下停掉的动画也省下了性能。
什么时候要查
- 用户说“滑起来一顿一顿”“弹窗出来有点卡”“手机发烫”。
- AI 写的动画里出现 width、height、top、left、margin 这类属性在变化。
- 页面上有大列表、长页面滚动动效、同时有很多元素在动。
- 只是按钮颜色的短过渡时一般不用专门查，但别写 transition: all。
怎么跟 AI 说，怎么验收
- 让 AI 列出动了什么：“列出每个动画改了哪些 CSS 属性；凡是改 width / height / top / left / margin 的，改成 transform 或 opacity 实现。”
- 电脑上模拟手机：Chrome 开发者工具 › 性能（Performance）› CPU 选 4× 降速，录制一次动画，看帧条有没有红色、有没有标红的长任务。
- 打开帧率显示：开发者工具 › 更多工具 › Rendering › 勾选 Frame Rendering Stats，动画时看帧率是否稳定。
- 真机过一遍：最后在一台中低端安卓机或旧 iPhone 上实际滑一遍，这一步不能省。
正反例：同一个效果，换一种写法
正例 · 顺抽屉滑入 卡片展开
先瞬间到最终高度，再用 transform 做缩放过渡布局只算一次，动画过程交给合成。
反例 · 卡抽屉滑入 每个元素都写 will-change
right: -320px → 0每帧都重新布局整页，手机上会掉帧，还可能挤动旁边内容。
* { will-change: transform }每个元素都单独占一块图层内存，手机反而更卡、更耗电；只给正在动的少数元素用。
快速自测
AI 说“侧边栏展开动画已优化，我在电脑上测试 60fps 很流畅”，代码里动画改的是 width。你下一步最该做什么？
继续查证
术语的技术定义和行为以这些一手或权威资料为准。
下一步学
和本知识点经常一起出现的概念。
用到这个知识点的案例
看看真实的项目蓝图里，动效性能是怎么被用上的。