核心思路是精准控制合成层：只对正在动画的可见元素动态添加will-change: transform，动画结束即移除；滚动列表中仅提升当前过渡项；避免父容器transform与子元素opacity组合触发隐式图层；用contain: paint/strict划定渲染边界防止图层污染；通过chrome devtools的layer borders和performance面板验证图层合理性；优先使用transform替代top/left实现位移动画以规避重排。
核心思路是：只对真正参与动画的元素按需提升合成层，同时限制其影响范围，避免图层数量失控。
精准触发合成层，而非全局强提
用 transform: translateZ(0) 或 will-change: transform 提升合成层本身没错，但关键在“谁来提”和“何时提”。对静态容器或未进入视口的元素提前加这些样式，等于主动制造冗余图层。
- 动画开始前动态添加
will-change: transform，动画结束立即移除 - 滚动区域内的列表项，只对当前可见且正在过渡的几项启用硬件加速，其余保持默认渲染流
- 避免在父容器上设置
transform同时又在子元素上设opacity—— 这类组合极易触发隐式图层提升
用 contain 属性划定渲染边界
即使某个元素被提升为合成层，它的样式变更仍可能引发父级或兄弟节点重绘。加上 contain: strict 或 contain: paint，能明确告诉浏览器：“这个区域的变化不会影响外部”，从而阻止图层污染扩散。
-
contain: paint阻止重绘溢出，适合图表、卡片等独立视觉模块 -
contain: strict同时限制布局、样式和绘制，适用于高度自包含的组件（如 ECharts 容器） - 注意不要滥用在有伪元素或浮动子元素的容器上，可能破坏原有布局逻辑
监控与验证图层结构是否合理
不靠猜测，用 Chrome DevTools 实时看真实图层分布：
- 打开 DevTools → Rendering 面板 → 勾选 “Layer borders”：蓝色边框=合成层，红色边框=渲染表面
- 在 Performance 面板录制动画过程，查看 “Layers” 轨迹，确认图层数量稳定、无突增
- 右键检查元素 → Elements 面板右侧的 “Styles” 中查找 “Composited layer” 标识，确认是否被正确提升
替代方案：优先用 transform 替代 top/left 动画
大规模位移动画卡顿，很多时候根本原因不是图层爆炸，而是频繁重排。把 top/left 改成 transform: translateX/Y，就能绕过布局阶段，只走合成流程。
- 批量更新时统一使用
transform，避免逐个写top触发同步布局计算 - 搭配
will-change: transform仅用于即将启动动画的元素，而非常驻样式 - 移动端尤其要注意，
translate3d(0,0,0)比translateZ(0)兼容性更稳
