原生 select 无法响应式适配高度，必须用 div+ul+li 模拟；ul 需设 max-height 和 overflow-y: auto，js 动态更新后需清空 style.height 并读 scrollheight；响应式关键在于按设备切换交互形态而非调整高度。
原生 select 高度无法响应式适配，必须换方案
浏览器对 select 的样式控制权收得极死：设 height、max-height、line-height 基本无效；appearance: none 只能隐藏箭头，不影响弹出层渲染；移动端（尤其 iOS Safari）还会因触摸热区限制（44×44px）导致点不中。一旦需要“内容多高就显示多高 + 滚动 + 不遮挡下方元素”，原生控件直接出局。
div+ul+li 模拟下拉时，max-height 必须写在 ul 上
这是最容易错的位置。很多开发者把 max-height 和 overflow-y: auto 加在父容器（如 .dropdown）上，结果滚动条作用于整个弹层，甚至把触发按钮一起卷走：
-
ul必须设max-height: 200px（或calc(5 * 48px)），不能设height或min-height -
ul的height: 100%是安全的——因为父级没写死高度，100% 实际等于auto - 父级
.dropdown绝对不要写height、min-height、overflow，否则会切断内容自然撑高逻辑
JS 动态更新选项后，高度没重算？先清空 style.height
用 JS 增删 li 后，下拉区域卡在旧高度，大概率是 DOM 上还挂着内联的 style.height="120px"，成了硬约束：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 每次操作前执行
dropdownUl.style.height = 'auto'，强制触发重排 - 别读
offsetHeight或clientHeight——它们不含溢出部分，永远比真实内容矮 - 只读
scrollHeight，它包含 padding 和全部内容所需空间 - iOS Safari 对
scrollHeight更新有微小延迟，包一层requestAnimationFrame更稳 - IE11 把
\r\n当一个字符算，scrollHeight偏小约 2px；可统一归一化：textarea.value = textarea.value.replace(/\r\n/g, '\n')
响应式断点不是加在 select 上，而是控制整个模拟组件结构
真正要响应的不是“下拉高度”，而是“是否启用弹出式交互”：
- 小屏（
@media (max-width: 768px)）建议切为全屏菜单或底部弹窗，避免手指误触相邻项 - 中屏可保留弹出式，但
max-height改为calc(100vh - 120px)，留出标题栏和返回按钮空间 - 桌面端若选项超 20 项，需配合虚拟滚动或搜索过滤——此时高度已不是重点，性能才是瓶颈
- 所有场景都必须配 CSS 的
min-height和max-height——JS 只管“当前要多高”，上下限得靠样式兜底
真正难的不是计算 scrollHeight，而是接受：自适应高度的本质是放弃控制，让流布局自己决定尺寸；而响应式设计的关键，从来不是“让下拉变矮”，而是“在不同设备上选对交互形态”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
