高度无法用css可靠控制，因浏览器将其视为系统级控件，height、padding等样式被ua强制忽略；唯一精确控制方式是放弃原生，改用++js自定义下拉组件。
<option></option> 的高度无法用 CSS 可靠控制，这不是你写错了，是浏览器根本没打算让你改。
为什么 height 和 padding 对 <option></option> 无效
绝大多数浏览器（Chrome、Edge、Safari、iOS/Android WebView）将 <option></option> 视为系统级控件的一部分，其渲染由操作系统或 UA 样式接管。你写的 height: 32px 或 padding: 6px 0 会被直接忽略——不是兼容性问题，是设计如此。
常见错误现象：
- 在 Firefox 中局部生效（比如某些版本允许
line-height），但换台机器或升级后就失效 - 写了
option { height: 40px; }，DevTools 显示样式“已应用”，但实际高度纹丝不动 - 用
appearance: none改了<select></select>外观，误以为也能穿透控制弹出层里的<option></option>—— 它不能
真正能影响“选项视觉密度”的两种路径
如果你的目标是让下拉菜单看起来更紧凑、更舒展，或避免文字挤在一起，只能绕开 <option></option> 本身：
- 调
<select></select>的padding：比如padding: 10px 12px，撑开选中区高度，间接提升文字垂直居中感（最轻量、兼容性最好） - 用
size属性控制可见行数：<select size="6"></select>强制显示 6 行（非下拉式，而是滚动列表），此时<option></option>高度仍不可控，但用户看到的是连续列表，心理上“行高”由line-height+padding在父容器中模拟 - 彻底放弃原生：用
<div> + <code><ul></ul>+ JS 实现自定义下拉，此时每个选项是<li>，height、line-height、padding全部自由——这也是唯一能精确控制单个选项高度的方式别踩这些坑：移动端 & 高对比模式下的意外
即使你用了自定义下拉组件，也容易漏掉关键约束：
- iOS Safari 要求触摸热区 ≥ 44×44px，强行把
<li>设成height: 24px，用户点不中 - Windows 高对比模式下，若自定义选项没设
color和background-color，可能变成全黑或全白，完全不可读 - Chrome 120+ 对 transform 缩放后的下拉触发可访问性警告，Lighthouse 直接标红 “form elements not scalable”
想改选项高度，本质是在「妥协可用性」和「重写渲染逻辑」之间选。没有中间路线——要么接受系统默认，要么自己造轮子。
- iOS Safari 要求触摸热区 ≥ 44×44px，强行把
