动画卡顿主因是使用非硬件加速属性（如left、width）触发重排重绘，应统一用transform/opacity，配合will-change、错峰动画、暂停非视口动画及优化JS交互。
动画卡顿是因为用了 transform 和 opacity 以外的属性
浏览器对 transform 和 opacity 做了硬件加速优化，而修改 width、height、top、left、background-color 等会频繁触发 layout 或 paint，导致掉帧。哪怕只改一个 margin，也可能让 60fps 的动画掉到 20fps。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把位移动画统一改用
transform: translateX(100px)替代left: 100px - 缩放/旋转用
transform: scale(1.2) rotate(15deg)，别用width+height - 显式声明
will-change: transform（仅对持续动画的元素，避免滥用） - 用 Chrome DevTools 的 Rendering > Paint flashing 查看哪些区域在反复重绘
用 CSS @keyframes 写动画时性能不稳
原生 @keyframes 没问题，但写法不当会拖慢渲染。比如在关键帧里混用 transform 和 filter，或在大量元素上同时播同一段动画，GPU 负载会飙升。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 避免在
@keyframes中使用filter（尤其是blur()）、box-shadow动画，它们开销极大 - 批量动画用
animation-delay错峰启动，别让上百个元素同时触发动画重排 - 用
animation-timing-function: cubic-bezier(0.17, 0.67, 0.83, 0.67)替代ease-in-out，减少中间帧计算压力 - 对非视口内元素暂停动画：
section:not(.in-view) { animation-play-state: paused; }
交互响应延迟——不是动画慢，是 JS 阻塞了主线程
常见场景：用户 hover 触发动画，但要等 JS 处理完 scroll 事件或数据请求才开始，误以为是 CSS 慢。实际上 CSS 动画本身是异步的，但 JS 绑定的 class 切换被卡住了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用
element.classList.add('animate-in')直接操作 class，别在事件回调里拼字符串再innerHTML - 把耗时逻辑移到
requestIdleCallback或 Web Worker，确保 class 切换不被阻塞 - 对高频事件（如
scroll、mousemove）加节流，避免每帧都调用classList.toggle - 启用
passive: true监听 touchstart/mouseenter，防止浏览器等待 JS 判断是否要 preventDefault
工具能帮上忙，但不能绕过渲染原理
像 anime.js、GSAP、Framer Motion 这类工具封装了时间轴和 easing，但底层仍依赖 CSS 属性选择。如果传给 gsap.to('.box', { x: 100, backgroundColor: '#ff0' })，后者照样会掉帧。
真正省心的用法是：
-
GSAP优先用x/y（映射为transform: translate），禁用left/top -
Framer Motion开启layout属性做布局动画时，注意它内部会用transform+opacity，但若子元素含position: absolute可能退化 - 用
anime.js控制 SVG 路径时，别直接动画d属性，改用stroke-dasharray+stroke-dashoffset
最易被忽略的一点：动画性能瓶颈往往不在“怎么动”，而在“动多少”——一个页面同时跑 50 个 transform 动画，比 5 个带 filter 的动画更吃 GPU。先减数量，再调写法。
