原生 的 height 仅影响顶部按钮区，无法控制下拉菜单高度；line-height 完全无效，因它是替换元素；size 属性可实现常驻列表并支持 css 控制，但破坏下拉交互；唯一精确可控方案是用 ++js 自定义，需兼顾可访问性、触控精度与性能。

原生 <select></select> 的 height 属性无法真正控制下拉弹出菜单的高度，只能影响顶部可点击区域的视觉高度；想精确控制整个下拉列表（含选项区）的高度，必须放弃原生渲染逻辑，改用自定义实现。

为什么 height 和 line-height 对 <select></select> 失效

浏览器把 <select></select> 拆成两部分：顶部“选中区”（CSS 可部分干预）和独立弹出的“下拉菜单”（由操作系统或 UA 绘制，CSS 无法穿透）。你设了 height: 40px，可能只压扁了按钮区，点开后仍显示 8–10 行默认高度的选项，滚动条位置、行高、项数全不可控。更关键的是：line-height 对 <select></select> 完全无效——它是替换元素，行高不由 CSS 行盒模型决定。

常见错误现象包括：

• Chrome / Edge 中 height 看似生效，但弹出菜单高度不变，且文字在按钮区内垂直偏位
• 给 <option></option> 加 padding 或 height，所有主流浏览器均忽略
• 移动端（尤其是 iOS Safari）对任何样式干预几乎无响应，还可能因热区过小导致点不中

用 size 属性控制可见行数（仅限非弹出模式）

size 是 <select></select> 原生支持的 HTML 属性，它让下拉框以“展开列表”形式常驻显示指定行数，此时 CSS height 才能稳定作用于整个容器。

适用场景：表单内嵌式选择器（如筛选条件栏），不需要点击才弹出。

Wechat HTML Publisher

直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

下载

• 设 size="5"，则始终显示 5 行选项，无弹出行为，height、padding、font-size 全部有效
• 搭配 multiple 可多选，但语义仍是单值提交（除非后端明确接收数组）
• 缺点：破坏“下拉”交互直觉，移动端易误触，且无法设置最大高度+滚动，内容超限时直接截断

示例：<select name="category" size="4"><option>A</option> <option>B</option></select>

真正可控：用 <div> + <ul> + JS 模拟下拉 <p>这是唯一能自由控制整体高度、滚动、行高、宽度、动画和键盘行为的方案。核心是隐藏原生 <code><select></select>，用语义化结构替代其视觉与交互。

• 下拉容器（<ul></ul>）设 max-height: 200px + overflow-y: auto，高度随内容自适应，超长即滚动
• 每项（<li>）可设 padding: 10px 12px、line-height: 1.5、min-height: 36px，完全自主
• 必须监听 click 外部区域关闭、Escape 键收起、ArrowDown/Up 键导航、Enter 确认
• 无障碍关键：原生 <select></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 条时，没加搜索过滤或虚拟滚动，首屏渲染卡顿，键盘导航响应延迟明显

真实项目里，高度控制从来不是孤立问题——它和可访问性、触控精度、性能表现绑在一起，动一个就得验一串。