原生 <select> 的 height 仅影响顶部按钮区，无法控制下拉菜单高度；line-height 完全无效，因它是替换元素；size 属性可实现常驻列表并支持 CSS 控制，但破坏下拉交互；唯一精确可控方案是用 <div>+<ul>+JS 自定义，需兼顾可访问性、触控精度与性能。
原生 <select> 的 height 属性无法真正控制下拉弹出菜单的高度，只能影响顶部可点击区域的视觉高度；想精确控制整个下拉列表（含选项区）的高度，必须放弃原生渲染逻辑，改用自定义实现。
为什么 height 和 line-height 对 <select> 失效
浏览器把 <select> 拆成两部分：顶部“选中区”（CSS 可部分干预）和独立弹出的“下拉菜单”（由操作系统或 UA 绘制，CSS 无法穿透）。你设了 height: 40px，可能只压扁了按钮区，点开后仍显示 8–10 行默认高度的选项，滚动条位置、行高、项数全不可控。更关键的是：line-height 对 <select> 完全无效——它是替换元素，行高不由 CSS 行盒模型决定。
常见错误现象包括：
- Chrome / Edge 中
height看似生效，但弹出菜单高度不变，且文字在按钮区内垂直偏位 - 给
<option>加padding或height，所有主流浏览器均忽略 - 移动端（尤其是 iOS Safari）对任何样式干预几乎无响应，还可能因热区过小导致点不中
用 size 属性控制可见行数（仅限非弹出模式）
size 是 <select> 原生支持的 HTML 属性，它让下拉框以“展开列表”形式常驻显示指定行数，此时 CSS height 才能稳定作用于整个容器。
立即学习“前端免费学习笔记（深入）”；
适用场景：表单内嵌式选择器（如筛选条件栏），不需要点击才弹出。
- 设
size="5"，则始终显示 5 行选项，无弹出行为，height、padding、font-size全部有效 - 搭配
multiple可多选，但语义仍是单值提交（除非后端明确接收数组） - 缺点：破坏“下拉”交互直觉，移动端易误触，且无法设置最大高度+滚动，内容超限时直接截断
示例：<select name="category" size="4"><option>A</option><option>B</option></select>
真正可控：用 <div> + <ul> + JS 模拟下拉
这是唯一能自由控制整体高度、滚动、行高、宽度、动画和键盘行为的方案。核心是隐藏原生 <select>，用语义化结构替代其视觉与交互。
- 下拉容器（
<ul>）设max-height: 200px+overflow-y: auto，高度随内容自适应，超长即滚动 - 每项（
<li>）可设padding: 10px 12px、line-height: 1.5、min-height: 36px，完全自主 - 必须监听
click外部区域关闭、Escape键收起、ArrowDown/Up键导航、Enter确认 - 无障碍关键：原生
<select>保留在 DOM 中（设position: absolute; opacity: 0; pointer-events: none;），同步更新其value和selectedIndex，并用aria-expanded、aria-controls关联状态
注意：不要只靠 transform: scale() 缩放原生控件——Chrome 120+ 已将其列为可访问性风险项，Lighthouse 会报错。
容易被忽略的兼容性雷区
即使你完成了自定义下拉，以下三点仍常被跳过，直接导致线上故障：
- iOS Safari 要求触摸目标最小为
44×44px，若自定义项height设为32px，用户大概率点不中 - Windows 高对比模式下，若未显式设置
color、background-color、border，菜单可能全黑或全白不可见 - 当选项超过 30 条时，没加搜索过滤或虚拟滚动，首屏渲染卡顿，键盘导航响应延迟明显
真实项目里，高度控制从来不是孤立问题——它和可访问性、触控精度、性能表现绑在一起，动一个就得验一串。
