iframe CSS动画异常的根源是父页面干扰其合成调度，需通过父容器加contain: layout paint style、移除body级transform/opacity/filter、精准控制will-change并验证Layer borders来实现独立合成。
iframe 里的 CSS 动画执行异常，基本不是动画写错了，而是父页面在干扰 iframe 的合成调度和渲染节奏——它把 iframe 拖进了自己的渲染流水线，导致动画掉帧、卡顿、甚至完全不触发。
为什么给 iframe 内元素加 will-change: transform 或 transform: translateZ(0) 没用
浏览器创建合成层要看整个渲染树上下文，不是只看 iframe 内部样式。如果父页面存在以下情况，iframe 内的层提升请求会被忽略或瞬时回退：
- 父页面的
body或外层容器设置了transform、opacity、filter—— 这会让整个页面压进单个合成层，iframe 失去独立性 - 父页面用了
will-change: all或长期驻留的will-change: transform，GPU 内存被占满，新层无法分配 - 父页面容器没加
contain: layout paint style，iframe 渲染树和父页面耦合，浏览器不敢为其单独建层 - DevTools 的 Layers 面板里 iframe 区域显示 “no layer” 或仅闪一下就消失，就是典型“伪加速”
真正起效的硬件加速必须从父容器隔离开始
目标不是“让 iframe 更快”，而是“让 iframe 能自己决定要不要加速”。关键动作必须落在父页面上：
- 给
iframe的**直接外层容器**（比如<div class="iframe-wrapper">）加上contain: layout paint style—— 这是最轻量且有效的隔离声明 - 绝对不要用
contain: strict，它会禁用 iframe 内部所有position: fixed，弹窗/下拉框全失效 - 删掉父页面中所有作用于
html或body的transform、opacity、filter，包括隐性写法如body { will-change: opacity } - 若必须局部加速，只对父页面中具体动画元素设
will-change: transform，且动画结束后立刻用 JS 清除：el.style.willChange = ''
如何验证是否真开启了独立合成
别信代码写了就生效，要靠浏览器反馈确认：
立即学习“前端免费学习笔记（深入）”；
- 打开 Chrome DevTools → Rendering → 勾选
Layer borders：iframe 区域应显示深色粗边框（表示已提升为独立合成层）；若只是浅灰细边，说明仍被父页面拖着走 - 勾选
Paint flashing：滚动或触发动画时，iframe 区域不应大面积红闪；若闪，说明父页面样式污染或重绘扩散 - Performance 面板录制动画过程：主线程的
Layout和Recalculate Style占比应极低；若持续高占比，问题仍在父页面
最常被忽略的一点是：父页面里那些“看起来没动，其实一直在动”的逻辑——比如没清理的 requestAnimationFrame、监听 scroll 时同步读取 getBoundingClientRect()、或频繁切换 v-show。它们不会报错，但会持续抢占 16ms 帧预算，让 iframe 的合成线程彻底失联。
