移动端多层嵌套动画卡顿的核心原因是每层混用非合成属性或意外触发重排/重绘；必须逐层严格仅用transform和opacity，禁用top/left/width/height等布局属性，并动态控制will-change、逐层验证绿色图层边框。
移动端多层嵌套动画卡顿，核心问题不是“层数太多”，而是每一层都混用了非合成属性、或在动画过程中意外触发重排/重绘——transform 和 opacity 仍是唯一安全出口，但嵌套时必须逐层隔离风险。
为什么嵌套动画比单层更容易掉帧
嵌套结构（比如 .carousel > .slide > .item > .badge）会让浏览器更难判断哪些元素能共用图层、哪些必须独立升层。一旦某一层用了 top 或动态改了 width，整个子树可能被迫回退到 CPU 渲染；更隐蔽的是，父容器的 overflow: hidden 或 filter: blur(1px) 会直接抑制子元素提层，导致绿色图层边框消失。
- 嵌套越深，JS 读取布局信息（如
getBoundingClientRect()）越容易误触同步重排 - 多个
@keyframes同时运行时，若任意一个关键帧含box-shadow或background-color，所有同级动画都会降级 -
will-change: transform在父元素上静态声明，不会自动继承给子元素，但可能因图层合并策略干扰子元素升层时机
嵌套结构中只允许用 transform + opacity 的实操约束
不是“尽量用”，而是强制隔离：每一层动画只能动且仅动这两个属性，且不能由 JS 动态插入其他样式。
- 位移统一走
transform: translateX(20px) translateY(-10px)，禁用left/top+position: relative组合 - 缩放/旋转写在同一个
transform值里：transform: scale(0.95) rotate(2deg)，别拆成多个transform声明 - 透明度切换必须用
opacity，不用rgba()改 alpha（后者仍属颜色重绘） - 禁止在任何嵌套层级的
@keyframes中出现margin、padding、height、width、box-shadow、filter（除简单blur(2px)外）
嵌套动画中 will-change 的动态控制要点
will-change 不是设在最外层就一劳永逸——它必须按“实际动的那层”单独控制，且只在真正需要的瞬间启用。
立即学习“前端免费学习笔记（深入）”；
- 不要写
.carousel { will-change: transform; }，这会让整组滑块提前占 GPU 内存 - 只对当前正在入场/出场的子项加 class：
.slide.is-active { will-change: transform; } - JS 添加时机：监听
touchstart或mouseenter后立即加 class，**不是**在animationstart时才加 - 移除时机：必须监听
animationend（不是transitionend），并加setTimeout兜底（iOS Safari 对短于 16ms 的动画可能不触发该事件）
验证嵌套动画是否真走 GPU 加速
写了 transform、加了 will-change，不代表有效——得看 DevTools 里有没有绿色图层边框，以及边框是否覆盖到你预期的那层。
- Chrome DevTools → Rendering → 勾选 “Layer Borders”：只有带绿框的元素才被提升为独立合成层
- 如果某层没绿框，检查它的父容器是否设置了
overflow: hidden、filter或backdrop-filter，这些会阻止子元素升层 - 打开 Layers 面板，展开后看每层的 “Composited Layer” 是否包含你目标的 DOM 节点；若显示 “Paints into ancestor”，说明它被合并进父图层，未独立升层
- 动画过程中禁用所有
getComputedStyle(el, 'transform')类调用——哪怕只读一次，也会强制同步 layout
嵌套动画最难缠的点在于：问题常不出现在你写的那一行 CSS 上，而出现在父容器一个被忽略的 overflow 声明、或兄弟元素一次无意的 offsetHeight 读取里。验证必须逐层下钻，不能只看顶层元素有没有绿框。
