响应式菜单卡顿的根本原因是错误使用left/top/max-height动画属性及will-change时机不当；应改用transform: scaleY()或transform位移，配合will-change动态设置与Layer borders验证GPU加速。
响应式菜单切换卡顿，根本原因不是“没开硬件加速”，而是动画属性选错 + will-change 用在了错误时机。只要还在用 left、top 或 max-height 做过渡，加再多 transform: translateZ(0) 都救不回来。
为什么用 max-height 过渡一定会卡
浏览器对 max-height 的动画无能为力——它不是合成属性，每次变化都强制触发 layout → paint 全流程。哪怕只设 max-height: 0 → 200px，浏览器也得逐帧重算内部文本流、行高、换行位置，CPU 直接拉满。
- 绝对不要写
transition: max-height 0.3s ease，这是响应式菜单卡顿最常见源头 - 替代方案只有两个：用
transform: scaleY()+transform-origin: top模拟展开；或直接用height: 0 → auto配合 JS 动态读取 scrollHeight 后用transform模拟（但更推荐前者） - 若必须保留内容可访问性，
visibility: hidden可以和transform组合使用，但绝不能和display: none一起用于过渡——后者会让元素瞬间脱离渲染树，动画直接失效
如何正确启用 GPU 加速并验证是否生效
加 will-change: transform 不等于加速，只是提示；真正起效的是 transform 和 opacity 本身。加速是否真实发生，必须靠 Chrome DevTools 的 Layer borders 看橙色边框。
- 菜单容器（如
.nav-menu）应设transform: translateY(-100%)（收起）→transform: translateY(0)（展开），全程只动transform - 在 JS 触发展开前 1 帧加
el.style.willChange = 'transform'，监听transitionend后立刻设回'auto'；iOS Safari 有时不触发transitionend，加兜底setTimeout(() => el.style.willChange = 'auto', 350) - 打开 DevTools →
Cmd+Shift+P→ 输入 “Rendering” → 勾选Layer borders；动画过程中看到橙色边框包裹菜单区域，才算真正升层；没边框？检查父级是否设了overflow: hidden或contain: paint，它们会抑制提层
媒体查询切换时菜单动画突然中断或错位
这不是动画写错了，是 @media 覆盖了关键帧状态，导致浏览器丢失动画上下文。比如桌面端用 transform: translateX，移动端改用 transform: scaleY，但没给各自定义独立 @keyframes 名，浏览器会复用旧规则，造成跳变。
立即学习“前端免费学习笔记（深入）”；
- 每个断点的动画逻辑必须拆开：桌面版写
@keyframes slide-in-desktop，移动端写@keyframes slide-in-mobile，避免同名冲突 -
@media内必须显式重写完整transition，例如transition: transform 0.25s cubic-bezier(0.34, 1.56, 0.64, 1); opacity 0.25s，不能只写transition-property: transform - 如果用户开启了系统级
prefers-reduced-motion，直接在根选择器加@media (prefers-reduced-motion: reduce) { .nav-menu { animation: none; transition: none; } }，别试图“降速”，要彻底关闭
最容易被忽略的一点：菜单动画卡顿常发生在媒体查询匹配完成、但 DOM 重排尚未结束的那几毫秒里。JS 如果在 resize 事件里立刻 classList.add('is-open')，大概率被卡住。应该用 requestAnimationFrame 包一层，确保样式变更发生在下一帧重排之后。
