关键在用 animation-play-state 控制启停，而非自动播放；CSS变量仅能驱动transition和部分属性，不能用于@keyframes；will-change需慎用，仅对transform/opacity等设且动画后及时清除；读写样式需分离并用requestAnimationFrame优化。
怎么让CSS动画响应用户操作而不是自动播放
关键在用 animation-play-state 控制启停，而不是依赖 animation-delay 或反复重写 @keyframes。自动播放的动画一旦加载就跑，交互时卡顿、重复触发、状态错乱全由此来。
常见错误现象：animation: slideIn 0.3s 写死在类里，点击按钮后多次触发，动画叠加或跳帧；或者用 setTimeout 强行加类，但没清上一次的动画状态。
- 把动画定义在独立类中（如
.is-animating），用 JS 切换这个类，而非直接操作style.animation - 需要暂停时设
animation-play-state: paused，恢复用running，注意它不重置动画进度 - 若要“重新播放”，必须先移除类再加回，或用
animation: none瞬间清空状态（兼容性好于animation-cancel） - 移动端要注意
prefers-reduced-motion: reduce，用@media关掉动画更尊重用户设置
CSS变量（--color-primary）怎么实时驱动动画和过渡
不能直接在 @keyframes 里用 CSS 变量——浏览器不支持。变量只能驱动 transition 和部分可动画属性（如 background-color、transform），但无法用于 animation 的关键帧计算。
使用场景：主题切换、深色模式、动态配色组件。比如按钮悬停时从 --color-primary 渐变到 --color-accent。
立即学习“前端免费学习笔记（深入）”；
- 给元素设
transition: background-color 0.2s, color 0.2s，然后 JS 改style.setProperty('--color-primary', '#3b82f6')，颜色会平滑过渡 - 想实现“滚动渐变背景”，别写
@keyframes bgShift，改用background-position+transition配合变量控制偏移值 - 变量值必须是合法 CSS 值（如
#fff、20px），传入'red'没问题，但传'calc(100% - 20px)'就可能失效——计算得提前在 CSS 里做 - Chrome 115+ 支持
animation-timeline配合scroll()，但变量仍不能进 keyframes，这点容易误判
用 will-change 提升动画性能，但为什么有时更卡
will-change 不是开关，是提示浏览器“这个元素接下来很可能变”，提前分配图层。滥用反而增加内存开销、触发不必要的合成，尤其在低端 Android 上更明显。
典型错误：给所有 :hover 元素加 will-change: transform；或在 JS 中频繁 toggle 它。
- 只对真正需要硬件加速的属性设它：优先
transform和opacity，别碰top、left或background-color - 动画开始前 1–2 帧设
will-change，动画结束立即removeProperty('will-change')，避免长期占用图层 - 用 Chrome DevTools 的 “Rendering” 面板勾选 “Paint flashing” 和 “Layer borders”，看是否真生成了新图层，而不是凭感觉加
- 如果元素本身已处于合成层（比如父级有
transform: translateZ(0)），再加will-change就多余
JavaScript 读写样式导致强制同步布局（Layout Thrashing）
这是动态网页最隐蔽的卡顿源：一边读 offsetHeight，一边立刻写 style.transform，浏览器被迫同步计算布局，阻塞主线程。
常见于轮播图、下拉菜单高度自适应、滚动视差等交互逻辑。
- 把所有读操作集中放在前面（如批量取
getBoundingClientRect()），所有写操作集中放后面（如统一设style） - 用
requestAnimationFrame包裹写操作，确保在下一帧执行；读操作尽量用offsetTop等缓存值，而非实时 DOM 查询 - 现代方案可用
ResizeObserver替代监听window.resize后反复读尺寸；用IntersectionObserver替代 scroll 事件里查元素位置 - 别信“加个
setTimeout就能破循环”，它只是把同步布局延后一拍，问题仍在
动态效果越复杂，越要警惕那些看似无害的 clientWidth、getComputedStyle 调用——它们不是免费的，而且很容易被链式调用藏得极深。
