为什么直接 transition max-height 不生效
因为 max-height: 0 到 max-height: auto 无法触发过渡动画——auto 不是可计算数值，浏览器不知道该从哪过渡到哪。
常见错误现象：max-height 看似写了 transition，但菜单始终“啪”一下弹出或消失，毫无平滑感。
- 必须用具体像素值（比如
max-height: 500px）替代auto - 初始状态设为
max-height: 0，同时配overflow: hidden - 展开时设一个足够大的固定值（如
max-height: 400px），确保内容完全可见 - 如果子菜单高度动态变化（比如文字长度不一），需预估最大可能高度，宁大勿小
如何让折叠动画真正“贴合内容高度”
纯 CSS 没法自动读取内容真实高度，所以得靠 JavaScript 补位：先获取 scrollHeight，再写入 max-height。
使用场景：导航栏下拉、FAQ 折叠区、移动端侧边栏菜单等需要响应式高度的交互。
- 展开前：用 JS 获取
element.scrollHeight，赋给style.maxHeight - 收起时：先设
max-height为当前高度，再用setTimeout设为0，触发过渡 - 记得在
transitionend后清理内联样式，避免影响后续操作 - 示例关键逻辑：
menu.style.maxHeight = menu.scrollHeight + 'px';
transition-duration 和 easing 怎么选才自然
太慢显得迟滞，太快像抽搐；easing 选错会让动画“一头栽下去”或“卡在半空”。
性能影响：所有 max-height 过渡都触发重排（reflow），但只要不频繁切换、高度不过大，实际感知不明显。
- 推荐时长：
transition-duration: 0.25s～0.35s，比默认0.3s略快更跟手 - easing 用
cubic-bezier(0.4, 0, 0.2, 1)（即ease-in-out的优化版），开头柔和、结尾收得稳 - 别用
ease——它前半段太慢，后半段又太急，折叠末尾容易“甩出去” - 移动端建议加
will-change: max-height，提前提示渲染层优化（仅在必要时）
IE 和旧版 Safari 的兼容性怎么兜底
IE10+ 支持 max-height 过渡，但 IE9 及以下完全不认；Safari 13.1 之前对 max-height 动画有渲染 bug，会闪动或跳变。
容易被忽略的地方：不是所有“支持 transition”的浏览器，都支持 max-height 的平滑插值。
- IE9 及以下只能降级为
display: none/block切换（无动画） - Safari transform: translateZ(0) 强制硬件加速，缓解闪动
- 不要依赖
@supports (max-height: 1px)来检测——它只测语法，不测动画是否真能跑 - 真要全兼容？老项目可引入
height+overflow组合，但需 JS 精确控制高度，复杂度翻倍
CSS 折叠菜单的“平滑”本质是骗过浏览器：用固定高度模拟动态内容，靠 JS 补足那点不确定性。最麻烦的从来不是写几行 transition，而是判断什么时候该切回 JS 控制、什么时候能放心交给 CSS——这取决于你愿不愿意为 1% 的旧设备多维护一套逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
