WAAPI 动画与 CSS 类切换互不响应，class 变更无法触发、暂停或覆盖 WAAPI 实例；需用 JS 显式控制动画状态，并避免 class 引发重排以保障性能。
直接用 class 切换控制动画，在 Web Animations API（WAAPI）场景下会失效或降级——因为 WAAPI 管理的是独立动画实例，不响应 CSS 类变更，也不自动接管已存在的 @keyframes 动画。
class 切换无法触发或中断 WAAPI 动画
WAAPI 创建的动画是 JS 运行时对象，与 CSS 类无绑定关系。即使你用 element.classList.add("animate-spin")，也不会启动、暂停或覆盖正在运行的 element.animate() 实例。
- WAAPI 动画一旦播放，就脱离样式表控制；
class变更只影响 CSS cascade，对已挂载的Animation对象无 effect - 若同时存在 CSS
@keyframes和 WAAPI 动画作用于同一属性（如transform），浏览器按“最后声明胜出”规则处理，但不会同步状态（比如 CSS 类停了，WAAPI 动画还在跑） - 常见误判：以为加了
active类就能让 WAAPI 动画开始，实际需显式调用animation.play()
用 class 控制 WAAPI 动画状态属于反模式
想靠 class 触发、暂停、重置 WAAPI 动画，必须手动监听类变化并桥接逻辑，徒增复杂度且易出错。
- 不要写
if (el.classList.contains("paused")) animation.pause()这类轮询或 MutationObserver 监听——性能差、时机难控 - 正确做法是把状态收口到 JS：用
useState（React）、ref（Vue）、或普通变量管理播放状态，再统一调用animation.play()/animation.cancel() - 如果非要保留 class 作为视觉标记（如加
is-animating类），请仅用作 CSS 样式钩子，而非控制信号
class 切换 + WAAPI 混用时的性能隐患
两者混用不一定会卡顿，但容易无意中触发重排/重绘，尤其在 class 变更导致 layout 属性（如 width、display）改变时。
立即学习“前端免费学习笔记（深入）”；
- WAAPI 动画本身推荐只操作
transform和opacity——但如果 class 切换同时改了margin或height，就会打断合成层，强制回退到 CPU 渲染 - 例如：
el.classList.toggle("expanded")若该 class 含height: auto，会触发布局计算，哪怕 WAAPI 正在平滑移动元素，整帧也可能掉到 40fps 以下 - Chrome DevTools 的 Layers 面板里能看到：class 切换后动画元素是否还保有独立合成层；若变成 “Shared with ancestor”，说明被降级了
真正要测 WAAPI 性能，得关掉所有 class 驱动的样式变更，只用 animation.playbackRate、animation.currentTime 和纯 transform/opacity 关键帧做压测——否则你测的不是 WAAPI，是 class 切换和样式的耦合开销。
