max-height过渡常卡顿或收不干净，因其依赖浏览器估算高度且max-height:auto不可动画，需配overflow:hidden、opacity、足够大的max-height值及显式transition声明。
为什么max-height过渡常卡顿或收不干净
直接用max-height: 0 → max-height: 300px做下拉过渡，表面看能动，但实际容易出现三类问题：收尾突然截断、展开时高度“弹跳”、移动端滚动卡顿。根本原因是max-height过渡依赖浏览器对高度的估算，而max-height: auto不可动画，你必须硬写一个“够用但不过量”的固定值——一旦内容超出，就会溢出；写小了，又撑不开。
- 过渡中若菜单内文字换行、图片加载完成、或JS动态插入内容，
max-height值就失效，动画直接跳变 -
max-height变化会触发重排（reflow），尤其在父容器有flex或grid布局时，掉帧明显 - 移动端 WebKit 内核对
max-height过渡优化差，常伴随1–2帧白屏或闪烁
max-height过渡必须配哪些关键样式才可控
如果仍想用max-height（比如兼容极老浏览器或已有项目难重构），必须补全以下四点，否则动画大概率失败：
- 初始状态设
max-height: 0、overflow: hidden、opacity: 0，三者缺一不可——仅靠max-height无法隐藏内容可点击区域 - 展开目标值不能写死
300px，改用足够大的值如max-height: 50rem（rem比px更适应字体缩放） - 过渡必须显式声明两个属性：
transition: max-height 0.3s ease, opacity 0.3s ease；漏掉opacity会导致透明前就占位，鼠标误触 - 父容器加
will-change: max-height仅在 hover/focus 激活前一刻用 JS 动态添加，避免常驻开销
比max-height更稳的替代方案：纯transform + opacity
真正平滑的多级下拉，应放弃max-height，改用transform: scaleY(0) + opacity: 0组合。它不触发布局计算，全程走合成线程，iOS 和安卓 WebView 均表现一致。
- 初始状态：
transform: scaleY(0); opacity: 0; visibility: hidden; transform-origin: top; - 展开状态：
transform: scaleY(1); opacity: 1; visibility: visible; - 过渡写在基础选择器上：
.dropdown-menu { transition: transform 0.25s cubic-bezier(0.34, 1.56, 0.64, 1), opacity 0.25s ease; } - 务必确保父级没设
transform（如scale(0.95)），否则transform-origin: top会偏移，导致缩放中心错位
多级菜单悬停断连时，max-height方案会彻底失效
当鼠标从一级菜单移向二级菜单，中间有空隙，:hover状态丢失，max-height立刻归零——你看到的是“闪退”，不是“收起”。这不是动画问题，是触发逻辑崩了。
立即学习“前端免费学习笔记（深入）”；
- 纯 CSS 解法：用
:focus-within替代:hover，给一级容器加tabindex="0"，再配合键盘导航，可访问性也达标 - 轻量 JS 方案：监听
mouseenter和mouseleave，加防抖（setTimeout延迟 200ms 隐藏），留出鼠标移动间隙 - 绝对不要在
max-height过渡中混用display: none——哪怕只在 JS 里写一次el.style.display = 'none'，整个过渡链就中断
max-height本身，而在你没意识到它和visibility、overflow、触发时机这三者的耦合有多紧。写死一个高度值是最省事的错法。 
