max-height过渡被选作折叠面板动效基础，因其可动画且能模拟height: auto；需预估合理阈值（如400px），配合媒体查询分层调整，并与overflow: hidden、transition等协同声明以避免抖动或溢出。
为什么max-height过渡常被选作折叠面板动效基础
因为height: auto无法直接过渡，而max-height是可动画的CSS属性，且能“假装”撑开内容。只要设一个足够大的值（比如max-height: 500px），就能覆盖多数内容高度，视觉上接近真实高度过渡。
但注意：这个“足够大”必须预估合理——设太小会截断内容，设太大（如max-height: 10000px）会导致动画变慢、布局抖动，尤其在低端设备上更明显。
- 移动端常见内容高度多在
200px–400px之间，建议初始设为max-height: 400px，再配合媒体查询微调 - 如果面板内含图片或异步加载内容，需确保
max-height在内容渲染完成后再生效，否则动画会从0跳到固定值 - 不要用
overflow: hidden以外的溢出处理——overflow: visible会让内容冲出容器，破坏折叠效果
如何用媒体查询适配不同断点下的max-height阈值
响应式不是只靠@media切换字体或间距，折叠面板的动效阈值也得随视口变化。小屏内容行数少，max-height可以设小些；大屏可能展开更多详情项，需要更高阈值。
关键不是写多个@media覆盖同一规则，而是按内容密度分层定义变量级阈值：
立即学习“前端免费学习笔记（深入）”；
- 在
@media (max-width: 768px)下，设max-height: 320px（适配单列列表+简短描述） - 在
@media (min-width: 769px) and (max-width: 1024px)下，升为max-height: 480px（支持两列缩略图+中等长度文本） - 桌面端默认用
max-height: 600px，但若检测到内容高度超过该值，应改用JS读取scrollHeight动态设置——纯CSS无法解决“未知高度”问题
transition写在哪个元素上？为什么不能只写max-height
必须把transition: max-height 0.3s ease-in-out写在折叠容器本身（即包裹面板内容的<div>），且要和<code>overflow: hidden、height: auto等一起声明。单独写max-height过渡看似可行，但实际会因浏览器重排策略导致卡顿或跳变。
- 务必同时声明
transition和will-change: max-height（仅对频繁触发的面板启用，避免滥用） - 不要在
:hover或.active类里只写max-height，漏掉overflow会导致展开时内容溢出 - 关闭状态建议用
max-height: 0+padding: 0+border: none组合清空视觉残留，否则有空白缝隙
遇到max-height过渡不流畅或“抽搐”的典型原因
这不是CSS写错了，往往是布局上下文干扰了过渡链路。最常被忽略的是父容器的display类型和内部子元素的margin坍塌。
- 父容器用了
display: grid或flex，但没设align-items: start，导致折叠时基线偏移，视觉上像“抖一下” - 面板内容第一行用了
margin-top，关闭状态下max-height: 0压不住它，会透出一点白边——应统一用padding替代首尾margin - 使用了
transform: scale()或filter: blur()等触发GPU加速的属性，反而和max-height过渡冲突，造成帧率骤降 - 某些安卓WebView对
max-height过渡支持不稳定，可加-webkit-transition前缀，但更稳妥的是在小屏下退回到opacity + height: 0/fit-content的JS控制方案
动效的本质是权衡：CSS方案轻量但有边界，真要兼顾各种内容长度和设备性能，max-height只是起点，不是终点。
