原生 select 无法真正自适应高度，因弹出菜单由系统/UA独立渲染且 CSS 不可穿透；唯一原生可控方案是 size 属性（常驻列表模式）；彻底解决需用 div+ul+JS 模拟下拉并流式约束。
原生 select 无法实现真正意义上的自适应高度——你设的 height、max-height、line-height 对弹出菜单全部无效，强行设置只会压扁顶部按钮区，或在不同浏览器中表现混乱。
为什么 select 的 height 和 max-height 基本没用
浏览器把 select 拆成两部分：顶部“选中区”（CSS 可有限干预）和底层独立绘制的弹出菜单（由操作系统或 UA 控制，CSS 完全不可穿透）。你写的 height: 40px 可能只影响按钮视觉，点开后仍显示默认 8–10 行，行高、滚动、项数全不受控。option 标签加 padding 或 height 会被所有主流浏览器静默忽略；line-height 对 select 本身也无效，它是替换元素，不走 CSS 行盒模型。
- Chrome/Edge 中设
height后文字常垂直偏位，弹出菜单高度纹丝不动 - iOS Safari 对任何样式干预几乎无响应，热区过小还容易点不中
-
appearance: none只能隐藏箭头，下拉层渲染逻辑完全不变
用 size 属性实现“伪自适应”（仅限非弹出场景）
size 是唯一原生支持、无需 JS 就能稳定控制可见行数的方案，但它放弃“点击弹出”交互，转为常驻列表模式。此时高度由行数 × 浏览器默认行高决定，且可被 CSS 配合控制。
-
<select size="4"></select>强制显示 4 行选项，超出自动滚动，height、padding、font-size全部生效 - 搭配
multiple可多选，但语义仍是单值提交（除非后端明确接收数组） - 移动端体验差：易误触、无弹出反馈、触摸热区难保障 ≥ 44×44px
- 别设
size="1"—— 某些旧版 Safari 会丢失下拉箭头，破坏可用性
真正自适应：用 div + ul + JS 模拟下拉
这是唯一能精确控制整体高度、滚动行为、行高、键盘导航和无障碍支持的路径。核心是隐藏原生 select，用语义化结构替代其视觉与交互，再通过 CSS 流式约束 + JS 同步状态。
立即学习“前端免费学习笔记（深入）”；
-
ul上必须设max-height（如max-height: 200px）和overflow-y: auto，禁用height或min-height - 每次 JS 动态增删
li后，先执行dropdownUl.style.height = 'auto'清空内联高度，再读scrollHeight（不是offsetHeight） - iOS Safari 读
scrollHeight有延迟，需包一层requestAnimationFrame；IE11 对\r\n计算偏小，建议统一归一化换行符 - 必须监听
click外部区域、Escape键、ArrowDown/Up导航、Enter确认，并同步aria-expanded和aria-controls
父容器滚动兜底（轻量应急方案）
如果你只是想防止长列表撑开页面、又不想重写整套逻辑，可绕过 select 本身，在包裹它的父容器上做限制。这不改变弹出菜单，而是控制其可视区域高度。
- 给
select外层div加position: relative，内部用 JS 模拟的ul作为下拉内容 - 该
ul设max-height: 240px+overflow-y: auto，而非设在父div上 - 绝对不要在父容器上写
height、min-height或overflow—— 这会切断内容自然撑高逻辑 - 若用
transform: scale()微调按钮区视觉高度，必须同步补偿margin-top和font-size，否则文字模糊、热区偏移
最难的不是写几行 CSS 或 JS，而是接受一个事实：所谓“自适应高度”，本质是放弃对弹出层的硬控制，转而用流式布局 + 滚动约束 + JS 辅助重排来逼近目标。iOS Safari 和 IE11 的 scrollHeight 计算差异、键盘导航的缺失、触摸热区不足——这些坑往往在上线前最后一刻才暴露。
