CSS动画适用简单状态切换（如悬停、展开），@keyframes用于多阶段自动动画，而用户交互响应、物理模拟、数据驱动链式动画必须用JS；性能关键在是否触发合成器。
CSS 动画能替代脚本动画，但只在它“管得住”的范围内——不是不能，而是不该、不值、不稳。
哪些场景用 transition 就够了，别碰 JS
简单状态切换类动效，CSS 的 transition 是最轻量、最可靠的选择。它天然绑定 class 变化，不占主线程，浏览器自动优化。
- 按钮悬停变色：
transition: background-color 0.2s ease，:hover改颜色即可 - 菜单展开收缩：用
max-height+overflow: hidden过渡（注意不能用height: 0 → auto，得设具体数值） - 卡片浮起+阴影增强：
transition: transform 0.25s, box-shadow 0.3s，配合:hover或.active - 淡入提示框：
opacity和visibility联动（display: none无法过渡，必须避开）
⚠️ 常见翻车点：transition: all 0.3s 看似省事，实则危险——可能意外触发 layout（比如改了 width）、重绘（比如改了 color），导致卡顿；务必只写真正要动的属性。
什么时候必须上 @keyframes + animation
需要自动播放、循环、或定义多阶段路径（非简单两态）时，@keyframes 是 CSS 动画的“进阶模式”。但它依然受限于声明式逻辑。
立即学习“前端免费学习笔记（深入）”；
- 加载旋转图标：
@keyframes spin { to { transform: rotate(360deg); } }+animation: spin 1s linear infinite - 气泡提示弹出+缩放+淡出：
0% → 50% → 100%分三段控制transform和opacity - 徽章数字跳动效果：靠
transform: scale()配合animation-timing-function: steps(1)实现“逐帧抖动”感
⚠️ 注意兼容底线：IE10+ 支持 animation，但 Safari 旧版需加 @-webkit-keyframes；若项目需支持 IE9，这类动画就得降级为 GIF 或 JS 回退。
JS 动画不可替代的三大硬需求
一旦出现以下任一情况，CSS 动画就该让位——不是它不行，是它根本没这个设计意图：
- 用户拖拽过程中实时跟随鼠标位置（
transform: translate(x, y)需每帧计算，transition有延迟，@keyframes无法响应输入） - 物理模拟：比如弹性回弹（bounce）、重力下落、碰撞检测——这些需要每帧更新速度/加速度/边界判断，纯 CSS 没有状态变量和条件分支
- 链式动画依赖数据：比如“列表项逐个入场”，入场时机由 API 返回数组长度决定，且中途可能被用户中断或重排——
requestAnimationFrame才能精确控制每一帧的起止与插值
? 小技巧：哪怕用 JS 控制动画，也尽量只改 transform 和 opacity，这两者可触发硬件加速；避免在动画帧里读写 offsetTop 或修改 width，否则强制同步 layout，直接掉帧。
性能真相：不是“CSS 快、JS 慢”，而是“谁更靠近合成器”
CSS 动画快，本质是因为浏览器把它交给了合成器线程（compositor thread），不阻塞 JS 主线程；而 JS 动画若只操作 transform/opacity 并用 requestAnimationFrame，也能走同一路线，性能差距极小。
- ✅ 推荐组合：
transform+opacity+will-change: transform（谨慎加，仅对频繁动画元素） - ❌ 性能杀手：
top/left定位动画（触发 layout）、box-shadow大范围模糊（重绘开销大）、filter: blur()（尤其在移动端） - ? 验证方法：Chrome DevTools → “Rendering” 面板勾选 “Paint flashing”，看动画期间是否大面积闪烁（说明在重绘）
真正容易被忽略的，是“动画是否真的需要被看见”——比如后台 tab 里的轮播图，CSS animation 默认仍会运行，而 JS 用 requestAnimationFrame 可监听 document.hidden 自动暂停。这点，CSS 做不到。
