大屏动画掉帧的根本原因是每帧触发重排，而非CPU/GPU性能不足；应仅使用transform和opacity等不触发布局的属性，并遵循读-写分离、图层提升、缓存读取、批量DOM操作等优化策略。
为什么大屏动画一卡就掉帧
根本原因不是CPU或GPU不够，而是每帧都在触发重排。比如用 left 和 top 做位移动画，浏览器必须每帧重新计算布局树——哪怕只是动一个数字，也会打断渲染流水线，帧率直接掉到 15–20fps。
真正能跑满 60fps 的只有走合成层的属性：transform（含 translate、scale、rotate）和 opacity。它们不碰 layout，只交由 GPU 合成。
- 别写
transform: translateX(10px)+transform: translateY(5px)两行——合并成transform: translate(10px, 5px)，否则第二次会覆盖第一次，还可能触发额外样式计算 -
transform: scale(1)在旧版 Safari 上可能不触发硬件加速；写成scale(1.0001)更稳妥 - 对
display: inline元素直接加transform，可能因 baseline 计算抖动导致意外重绘；先设display: inline-block或block
怎么让图表容器真正“隔离”不拖慢整页
光加 transform 不够——元素还在文档流里，父容器仍要为它预留空间、参与行高计算。真正隔离靠图层提升（layer promotion），不是视觉错觉。
- 最通用写法是
transform: translateZ(0)；will-change: transform在 Safari 上支持弱，且容易误触发，慎用 - 别给静态图标、文字块加图层提升——它们不动，却长期占用 GPU 内存
- 多个相邻动画图表，建议包进同一个
<div>，只对该容器提升图层，而不是每个子项都单独提升 - 提升后行为类似
position: absolute；如果布局错位，检查是否依赖了原本的文档流位置（比如用margin-top对齐）
requestAnimationFrame 里读取位置为什么反而更卡
在 requestAnimationFrame 回调里调用 getBoundingClientRect() 或 offsetTop，等于强制浏览器立刻 flush 队列、同步重排——动画越快，打断越频繁，性能越崩。
立即学习“前端免费学习笔记（深入）”；
- 把所有读操作（如尺寸、位置）集中到一帧开头；所有写操作（如设
transform）集中到结尾，即严格“读-写分离” - 如果必须做碰撞检测或边界判断，缓存一次结果，在后续 2–3 帧内复用，而不是每帧都读
- 避免在循环中反复调用
getComputedStyle()、clientWidth等触发 layout 的属性
批量更新 DOM 时最容易被忽略的细节
用 innerHTML 或连续 appendChild 更新 50 个指标卡片？每次都会触发重排。这不是“慢一点”，而是让主线程反复进出 layout 阶段，大屏刷新瞬间就会撕裂。
- 用
DocumentFragment缓存节点，最后一次性插入：比拼接字符串更安全，也避免 HTML 解析开销 - 优先用
element.classList.add()切换预设 CSS 类，而非逐个赋值style.xxx；后者每设一次就可能触发一次重排 - 对频繁变动的容器，提前设
contain: paint，缩小重绘范围——浏览器知道“这块区域改了，其他不用管” - 绝对不要用
table布局大屏看板；它的重排代价是同等 flex 容器的 2–3 倍，且无法被图层提升绕过
复杂点不在“怎么做”，而在“什么时候不该做”：比如 will-change 不是开关，translateZ(0) 不是万能胶，缓存位置也不是永远可靠——得看数据更新频率、设备 GPU 能力、以及 Safari 的实际表现。这些细节没对齐，优化就变成新瓶颈。
