用max-height做下拉动画更可行，因height无法过渡auto值；需设合理上限（如400px）、配合overflow:hidden，并注意移动端渲染、无障碍及响应式适配。
为什么用 max-height 做下拉动画比 height 更可行
直接对 height 设置 0 → auto 的 CSS 过渡无效，浏览器无法计算 auto 的具体数值，动画会直接跳变。而 max-height 是可过渡的数值属性，只要设一个“足够大但不过分夸张”的上限值（比如 500px），就能模拟出展开/收起的渐变效果。
注意：这个值必须大于下拉内容在最大情况下的真实高度，否则动画会提前截断；但也不能设成 10000px 这类离谱值，否则在低性能设备上可能引发重排延迟或动画卡顿。
- 推荐值范围：
max-height: 0→max-height: 400px（适用于最多 8–10 行文字 + 图标） - 若列表项高度差异大（如含图片、多行文本），优先用
fit-content配合 JS 动态读取真实高度，而非硬编码max-height - 必须同时设置
overflow: hidden，否则内容会在动画过程中溢出显示
如何让 max-height 动画在移动端也顺滑
移动端 Safari 和部分 Android WebView 对 max-height 过渡的渲染优化较差，容易出现掉帧。关键不是加 will-change，而是控制触发时机和硬件加速层级。
- 给下拉容器添加
transform: translateZ(0)或backface-visibility: hidden，强制启用 GPU 合成层 - 避免在
:hover上直接触发动画（PC 可用，但移动端无 hover），改用.is-open类配合 JS 切换 - 动画时长建议设为
250ms，过长（如400ms）在快速连续点击时易产生状态错乱 - 不要对
opacity和max-height同时过渡——opacity会干扰浏览器对高度变化的预测，导致动画不连贯
max-height 动画与无障碍（a11y）的冲突点
用 max-height: 0 + overflow: hidden 隐藏内容时，屏幕阅读器仍会读取 DOM 中存在的元素，但视觉上不可见，这会造成信息暴露不一致。更糟的是，如果只靠 CSS 控制显隐而没同步更新 aria-expanded 和 aria-hidden，键盘用户按 Tab 进入下拉项时可能卡住或跳过。
- 必须用 JS 在切换时同步操作：
button.setAttribute('aria-expanded', 'true')和list.setAttribute('aria-hidden', 'false') - 下拉容器需有
role="menu"，子项用role="menuitem"，并确保焦点可进入（不能靠tabindex="-1"拦截） - 收起状态下，除了
max-height: 0，还要加visibility: hidden（注意：不是display: none，否则屏幕阅读器完全忽略）
响应式断点下如何安全调整 max-height 临界值
不同屏幕宽度下，下拉项的字体大小、行高、内边距都会变化，导致真实高度浮动。如果所有断点共用一个 max-height 值，小屏下可能撑不开，大屏下又显得拖沓。
- 在
@media (max-width: 768px)中把展开值从400px降到320px，适配缩小的行高和 padding - 避免在媒体查询里重复写整套动画规则，只覆盖
max-height和overflow即可 - 若使用 CSS 自定义属性（如
--dropdown-max-height: 400px），可在 JS 中通过getComputedStyle读取当前生效值，用于动态计算动画起点
真正难的不是写出动画，而是让 max-height 的“足够大”在各种字体加载、行高计算、缩放比例下都刚好够用——多数线上项目最终还是退回到 JS 测量真实高度 + height 过渡，只是把 max-height 当作降级兜底方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
