只有transform、opacity、filter（部分）、backface-visibility等属性动画能真正跑在合成线程上，不触发layout和paint，仅走composite阶段；而left、top、width、height、background-color等会触发布局或重绘，性能大幅下降。
哪些 CSS 属性动画能真正跑在合成线程上？
只有修改 transform、opacity、filter（部分）、backface-visibility 这几类属性时，浏览器才大概率不触发 layout 和 paint，只走 composite 阶段——这是 CSS 动画高性能的核心前提。
一旦你写 left、top、width、height、background-color（非 opacity 叠加）等属性，浏览器就得回流或重绘，性能立刻掉到和 JS 动画同一起跑线，甚至更差（因为 CSS 无法干预中间帧）。
- ✅ 安全组合：
transform: translateX()+opacity - ⚠️ 风险操作：
margin-left: 10px或color: #ff0触发动画时会强制同步计算样式 - ? 小技巧：加
will-change: transform可提前提示浏览器升层，但别滥用——只在动画即将开始前设，结束后及时清除
什么时候必须用 JavaScript 动画？
CSS 动画本质是“声明式”的，它只回答“变成什么样”，不回答“怎么变”或“什么时候变”。一旦逻辑里出现条件分支、用户拖拽、滚动联动、数据驱动节奏（比如根据 API 返回的数值决定动画时长），CSS 就无能为力了。
- 需要监听动画进度并做 DOM 操作（如：动画到 70% 时显示 tooltip）→ 只能用
requestAnimationFrame手动控制 - 多个元素要按队列逐个入场（ stagger ）→ CSS 的
animation-delay难以动态计算，JS 更直接 - 动画中途要响应鼠标事件暂停/反向/跳转 →
element.getAnimations()能读取当前状态，但控制粒度远不如 JS 自己维护的position变量 - 要做贝塞尔曲线运动、物理弹跳、视差滚动 → 必须靠 JS 计算每帧坐标，CSS 关键帧写不出来
requestAnimationFrame 为什么比 setTimeout 更稳？
setTimeout 是基于系统时钟的粗略调度，容易因主线程阻塞而丢帧；requestAnimationFrame 则由浏览器统一协调，保证回调总在下一帧绘制前执行，且在 tab 不可见时自动暂停，省电又省资源。
但注意：它本身不解决性能问题——如果你在 requestAnimationFrame 回调里做了强制同步布局（比如读取 offsetTop 后立刻改 style.left），照样触发回流，卡顿照旧。
- ❌ 错误写法：
el.style.left = el.offsetTop + 'px'（读写混用，强制同步 layout） - ✅ 正确姿势：用
getBoundingClientRect()批量读，用transform批量写，把读写操作分离开 - ⚠️ 兼容提醒：
requestAnimationFrame在 IE10+ 支持，但旧安卓 WebView 有 bug，需加 polyfill 或降级为setTimeout(..., 16)
CSS 动画的“可控性幻觉”是怎么回事？
很多人以为给元素加 animation-play-state: paused 就等于“暂停动画”，其实这只是冻结当前帧——它既不能告诉你当前进度百分比，也不能在任意时刻插入回调，更不能把动画倒着播一遍。所谓“暂停”，只是浏览器停止推进时间轴，背后没有状态机。
而 JS 动画里一个 progress 变量、一个 isPlaying 标志位、一个 reverse() 方法，就能实现完整生命周期控制。
- CSS 动画想监听“播完”只能靠
animationend事件，但无法区分是正常结束还是被cancel()中断 - 想让动画从 30% 开始播？CSS 没接口；JS 只需设置初始
progress = 0.3即可 - 动画中要根据用户输入实时调整速度？CSS 的
animation-duration是静态的；JS 可随时重算帧间隔
真正复杂的交互动画，最后都会暴露 CSS 的表达边界——不是它不行，是它的设计目标本就不是为了运行时干预。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
