要实现60fps dom状态切换动画，需用transform/opacity替代布局属性，配合will-change动态启用与requestanimationframe同步渲染，并通过devtools验证图层与帧耗时。
要让 DOM 状态切换（比如显示/隐藏、展开/收起、主题切换）产生顺滑的 60FPS 动画，关键不是“多做”，而是“做对”：把动画交给 GPU 处理，同时避免主线程被布局重排或样式强读拖垮。will-change 是提示信号，不是万能开关；GPU 加速是结果，不是魔法。
只对真正动的元素启用 will-change
will-change 的作用是提前告诉浏览器：“这个元素接下来要频繁变化，请为它准备独立合成层”。但它不解决动画逻辑本身的问题——如果动画属性本身触发重排（如修改 width、top、left），加了 will-change 也没用，甚至更卡。
- ✅ 正确做法：只对使用 transform 或 opacity 的元素设置 will-change: transform 或 will-change: opacity
- ❌ 错误做法：给一个靠 margin-top 实现位移的弹出菜单加 will-change: margin（该值无效，且无法触发硬件加速）
- ? 小技巧：用 JS 动态控制，状态切换开始前设 style.willChange = 'transform'，动画结束时设回 'auto'，避免长期占用 GPU 内存
用 transform/opacity 替代布局类属性
DOM 状态切换动画最容易掉帧，是因为开发者习惯用显示/隐藏 + top/left/margin 控制位置。这些操作强制浏览器反复计算布局（Layout），一帧内耗光 16.67ms。
- ✅ 推荐组合：visibility: hidden + transform: translateY(-100%) 控制隐藏；用 transition: transform 0.25s ease-out 实现入场
- ✅ 主题切换中，用 CSS 变量改色，再配合 opacity 淡入淡出，全程不触发布局
- ⚠️ 注意：不要用 translateZ(0) “硬撬”加速——它是过时 hack，现代浏览器更倾向依赖 will-change + 合理属性组合
状态切换动画必须与渲染节奏对齐
即使用了 GPU 加速，如果 JS 在滚动或点击后立刻批量修改多个元素的 class 或 style，仍可能因任务堆积导致丢帧。要让动画帧和屏幕刷新同步。
- ✅ 把状态更新包裹在 requestAnimationFrame 中，例如：点击按钮后，先加 loading class，再在 rAF 回调里触发 transform 动画
- ✅ 配合节流：高频交互（如快速切换 Tab）下，限制状态变更频率，每 16ms 最多响应一次，避免动画队列爆炸
- ❌ 避免在状态切换回调里读取 offsetHeight、getComputedStyle 等强制同步 Layout 的操作
验证是否真达到 60FPS
别只信感觉——用工具确认 GPU 层是否生效、主线程是否空闲。
- ✅ Chrome DevTools → Rendering → 勾选 Paint flashing 和 Layer borders：动画元素应有独立图层边框，且闪烁区域极小（仅内容变化处）
- ✅ Performance 面板录制动画过程，看每帧耗时是否稳定 ≤ 16ms，重点关注 Layout 和 Recalculate Style 是否几乎为零
- ✅ 使用 Lighthouse 的 Animations 审计项，检查是否有非合成属性被动画化
