原生 select 不支持高度自适应，须用 div+ul+li 模拟；ul 必设 max-height 和 overflow-y: auto，禁用 height/min-height；JS 更新后需清空 style.height 并读取 scrollHeight，注意 iOS Safari 和 IE11 的兼容细节。
下拉列表（select）原生不支持高度自适应内容，必须换方案：用 div + ul + li 模拟，再配 CSS 流式布局和滚动控制。
为什么不能直接改 select 的 height
浏览器对 select 元素的样式限制极严：height、max-height、overflow 基本无效；设置后要么被忽略，要么在不同浏览器中表现不一致（如 Chrome 强制最小行高，Safari 渲染错位）。连 appearance: none 也只管外观，不开放内部尺寸控制权。
ul 滚动容器必须设 max-height 而非 height
让下拉区域既能随内容撑开、又不遮挡下方按钮，关键在滚动容器的约束逻辑：
-
ul上必须设max-height（如max-height: 200px），不能设height或min-height -
ul的height: 100%是安全的——因为父级.dropdown没写死高度，100%实际等价于auto -
overflow-y: auto必须放在ul上，而不是父级.dropdown；否则滚动条会作用于整个弹层，而非仅内容区 - 避免在
.dropdown上写height、min-height或overflow，否则会切断内容自然撑高逻辑
内容更新后高度没变？先清空内联 style.height
如果用 JS 动态增删 li，发现下拉区域没重算高度，大概率是旧的 style.height 还挂在 DOM 上，成了硬约束：
立即学习“前端免费学习笔记（深入）”；
- 每次操作前执行
dropdownUl.style.height = 'auto'，强制触发重排 - 不要依赖
offsetHeight或clientHeight——它们不含溢出部分，永远比真实内容高度小 - 真要 JS 辅助，只读
scrollHeight，它包含 padding 和全部内容所需空间 - 移动端注意：iOS Safari 对
scrollHeight更新有微小延迟，加requestAnimationFrame包一层更稳
IE11 和 iOS Safari 的两个隐藏坑
这两个环境对高度计算特别敏感，不处理就会出现“删完文字高度不缩”“粘贴后底部留白”“光标跳动”等问题：
- iOS Safari：必须在
input或内容变更后，用requestAnimationFrame延迟读取scrollHeight，setTimeout(..., 0)不够可靠 - IE11：把
\r\n当一个字符算，导致scrollHeight偏小约 2px；可统一做换行符归一化：textarea.value = textarea.value.replace(/\r\n/g, '\n') - 所有场景都必须配 CSS 的
min-height和max-height——JS 只管“当前要多高”，上下限得靠样式兜底 - 别忘了
box-sizing: border-box，否则 padding 和 border 会让高度计算和视觉脱节
真正难的不是写几行 CSS 或 JS，而是意识到：自适应高度的本质是放弃控制，让流式布局接管。一旦你给父容器写了 height，或在 JS 里反复设 style.height，就等于亲手关掉了这个机制的开关。
