移动端CSS动画发热的根本原因是Layout/Paint持续占用主线程，导致CPU高负载；应改用transform/opacity等仅触Composite的属性，并动态控制will-change与可见性检测。
移动端CSS动画发热严重，根本原因不是“动画本身耗电”，而是动画持续触发高开销渲染流水线（尤其是 Layout 和 Paint），迫使 CPU 长时间满负荷运行；GPU 虽参与合成，但若图层管理失控或主线程被拖累，最终仍由 CPU 承担调度、计算、同步等重活。
为什么移动端动画一开就烫手？Layout/Paint 占满主线程
在中低端安卓机或 iOS Safari 中，top、left、width、height、margin 等属性动画每帧都强制触发 Layout + Paint，而移动端 CPU 缓存小、散热差，16ms 内完不成就会掉帧，浏览器只能反复重试——CPU 持续 90%+ 占用，发热自然明显。实测发现：20 个元素用 left 动画滚动，A12 芯片设备表面温度 5 分钟内上升 4.2℃；改用 transform: translateX() 后，温度几乎无变化。
常见诱因包括：
- 轮播图/列表项使用
left或margin-left做位移 - 下拉刷新控件里用
height控制加载条展开 - 弹窗动画同时修改
opacity和box-shadow（后者触发 Paint） - 父容器设了
overflow: hidden，导致子元素无法提升为独立合成层
只换属性不改逻辑：用 transform/opacity 替代 layout 属性
这是见效最快、兼容性最好的调优动作。核心是让动画路径缩到仅触发 Composite 阶段。
对照替换建议：
-
left: 100px→transform: translateX(100px) -
top: 50px→transform: translateY(50px) -
width: 200px→transform: scaleX(2); transform-origin: left center -
opacity: 0.5安全，但避免和background: linear-gradient()或多层box-shadow同时动画
注意：translate3d(0, 0, 0) 在 Chrome 115+ 和 Safari 17+ 已不稳定，优先用 translateZ(0) 或直接靠 transform 自动升层；不要为了“加速”硬加，否则可能因图层数爆炸反而增加内存与合成开销。
will-change 不是开关，是手术刀：必须动态控制生命周期
will-change: transform 的作用是提示浏览器“这个元素即将变化，请提前准备合成层”，但它不保证加速，滥用还会吃内存、拖慢首屏。
正确做法是 JS 控制其存在时机：
- 动画开始前 1 帧（用
requestAnimationFrame）设element.style.willChange = 'transform' - 动画结束时监听
transitionend或在requestAnimationFrame回调里清空：element.style.willChange = 'auto' - 绝对不要在 CSS 里全局写
will-change: transform，尤其别加在body或滚动容器上
补充一个关键细节：iOS Safari 对 will-change 响应较慢，建议搭配 backface-visibility: hidden 使用，能更可靠地锁定图层提升。
隐藏页签还在发热？说明你在用 requestAnimationFrame
CSS @keyframes 和 transition 在标签页隐藏时，浏览器会自动暂停合成线程，CPU 几乎归零。如果你发现切走后手机还在发烫，那大概率是 JS 动画没停——比如轮播图用 setInterval 或 requestAnimationFrame 手动驱动 style.transform 更新。
必须做可见性判断：
- 监听
document.addEventListener('visibilitychange', () => { ... }) - 在
document.visibilityState === 'hidden'时调用cancelAnimationFrame(id)或暂停定时器 - 恢复显示时重新启动，避免堆叠未执行帧
特别注意：Safari 和部分安卓 WebView 对后台节流不严格，getBoundingClientRect() 这类同步 Layout API 在隐藏页签里调一次，就等于主动触发一次重排——务必删掉所有这类读取操作。
真正难的不是选对属性，而是克制“加一层保险”的冲动：will-change 多加一层、translateZ(0) 多套一次、box-shadow 多叠一重，这些看似无害的操作，在移动端叠加起来就是发热和掉帧的温床。优化的终点，往往是删代码，而不是加代码。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
