适合用 transform 和 opacity 动画的元素需满足：仅含平移、缩放、旋转及透明度变化；强制提升合成层（如 translateZ(0)）；避免影响布局的 display 或尺寸缺失；移动端优先用 transform 触发硬件加速；配合 contain 隔离绘制范围；使用 requestAnimationFrame 调度并避免同步布局计算；合理控制合成层数量以防 GPU 内存压力。
哪些元素适合用 transform 和 opacity 动画
只有 transform（平移、缩放、旋转）和 opacity 触发合成层，不触发重排（reflow）和重绘（repaint），性能最优。其他 CSS 属性如 left、top、width、background-color 会强制浏览器走完整渲染流水线，帧率容易掉。
- 动画目标必须是独立图层（layer）——通常靠
will-change: transform或transform: translateZ(0)强制提升 - 避免对
display: inline或未设置宽高的元素直接加transform，可能因布局不稳定导致意外重绘 - 移动端 Safari 对
will-change支持较弱，更推荐用transform: translateZ(0)或transform: scale(1.0001)触发硬件加速
如何用 contain 隔离动画区域
contain: layout paint style 能告诉浏览器：“这个容器内部的变化不会影响外部布局和绘制”，从而缩小重绘范围。它比单纯加 transform 更进一步——不仅跳过重绘，还限制浏览器检查影响的区域。
- 适用于轮播图容器、弹窗、下拉菜单等局部频繁变化的模块
- 不要滥用：若容器内有子元素需响应外部尺寸变化（比如 flex 子项依赖父容器宽度），
contain: layout会阻断这种通信，导致布局错乱 - Chrome 85+ 支持完整
contain，旧版可降级为contain: paint（只隔离绘制）
为什么 requestAnimationFrame 比 setTimeout 更稳
requestAnimationFrame 由浏览器统一调度，在下一帧绘制前执行，天然对齐屏幕刷新节奏；而 setTimeout 的回调时间不可控，容易错过帧或连续触发造成卡顿。
- 动画逻辑必须写在
requestAnimationFrame回调里，且每次执行完要主动递归调用自己 - 避免在回调中读取
offsetTop、getBoundingClientRect()等触发同步布局计算（forced synchronous layout），否则会打断渲染流水线 - 如果动画需暂停/恢复，用
cancelAnimationFrame清理，否则残留回调持续占用主线程
合成层太多反而拖慢性能？怎么查和减
每个合成层都占用 GPU 内存，过多图层会导致内存压力大、纹理上传变慢，尤其在低端 Android 设备上明显卡顿。Chrome DevTools 的 Layers 面板（Rendering → Paint flashing + FPS meter）能直观看到哪些元素被提升、占多少内存。
立即学习“前端免费学习笔记（深入）”；
- 检查是否对非动画元素误加了
transform: translateZ(0)—— 比如静态图标、文字块 - 多个相邻动画元素尽量包裹进同一个父容器，对该容器提升图层，而非每个子元素单独提升
- 用
chrome://gpu确认硬件加速是否真正开启；部分企业环境或老旧驱动下，GPU 合成可能被禁用，此时强制提升图层无效
position: absolute），可能影响 z-index 层叠顺序、遮罩行为或 pointer-events 传递。动效上线前务必在真机上验证交互是否正常。 
