根本原因是使用height、top、left或display等触发重排的属性，迫使浏览器同步计算文档流并阻塞主线程；应改用transform+opacity组合实现GPU加速动画，并在各断点显式声明transition规则，配合requestAnimationFrame确保layout完成后触发动画。
为什么响应式菜单展开时会卡顿掉帧
根本原因不是动画写得不够“炫”，而是用了 height、top、left 或 display 这类触发重排的属性。浏览器一改这些值，就得同步计算整个文档流——主线程立刻被堵死，尤其在 Android WebView 或低端 iOS Safari 上，直接掉到 20fps 以下。
常见现象包括：汉堡按钮点击后菜单“啪”一下弹出来、滑动过程跳帧、缩放窗口时菜单反复闪动。DevTools Performance 面板里能看到大量 Layout 和 Paint 占比飙升，这就是重排重绘在拖后腿。
必须用 transform + opacity 实现展开动画
菜单容器（比如 .nav-menu）的位移和显隐，只能靠 transform: translateY() 和 opacity 驱动，这是唯一能走 GPU 合成线程、绕过重排重绘的组合。
- ✅ 正确写法：
transition: transform 0.3s ease, opacity 0.3s ease; - ❌ 错误写法：
transition: height 0.3s ease;或transition: top 0.3s ease; - 菜单隐藏时用
transform: translateY(-100%); opacity: 0;，展开时设为transform: translateY(0); opacity: 1; - 别混用：
@keyframes里只保留transform和opacity，删掉所有height、margin、box-shadow
媒体查询中 transition 必须显式重声明
浏览器不会继承或补全被覆盖的 transition 规则。如果你只在默认样式写了 transition: transform 0.3s，而在 @media (max-width: 768px) 里只加了 animation 或没写 transition，那这个断点下的过渡就实际失效了。
立即学习“前端免费学习笔记（深入）”；
- 每个断点都要完整写出要过渡的属性、时长和缓动函数，例如：
transition: transform 0.3s cubic-bezier(0.34, 1.56, 0.64, 1), opacity 0.3s ease; - 避免不同断点共用同一套
@keyframes名称；移动端用slide-mobile，桌面端用slide-desktop，防止规则冲突 - 桌面端若不需要动画，显式禁用：
@media (min-width: 769px) { .nav-menu { transition: none; } }
JS 触发动画前必须等 layout 完成
监听 resize 或点击事件后，不能立刻加 open 类——这时候 DOM 还没完成重排，动画会被卡在第一帧。必须用 requestAnimationFrame 确保样式变更发生在 layout 之后。
- 正确触发方式：
window.addEventListener('click', () => { requestAnimationFrame(() => { menuElement.classList.add('nav-menu--open'); }); }); - 如果用了
ResizeObserver，同样要在回调里包一层requestAnimationFrame，不能直接操作 class - 动画结束后，记得清理
will-change：menuElement.style.willChange = 'auto';（iOS Safari 可能不触发transitionend，加setTimeout兜底）
最易被忽略的是：动画容器没做 contain: layout paint 隔离，导致父级重排波及整个菜单；还有人把 will-change: transform 写死在 CSS 里，结果一屏 20 个菜单项全占着 GPU 内存——这些细节不处理，再“正确”的 transform 也救不回帧率。
