size属性是控制多选下拉框初始可见行数的唯一可靠方式，直接指定显示行数且跨浏览器一致；对单选下拉框，height仅影响按钮区，无法控制弹出菜单高度。
用 size 属性控制多选下拉框的初始可见行数
如果你用的是 <select multiple>，size 是唯一可靠、语义正确且跨浏览器一致的初始高度控制方式。它直接指定默认展开时显示多少行选项，不依赖 CSS，也不触发任何渲染兼容性问题。
常见错误是给 multiple 下拉框加 height 或 line-height —— 这些在 Chrome/Firefox/Safari 中要么无效，要么导致滚动异常或焦点错位。
-
size="4"表示默认显示 4 行选项（含滚动条空间），用户无需点击即可看到全部或部分选项 - 不设
size时，多数浏览器默认只显示 2 行，非常容易误判为“没加载完” -
size值过大会撑开页面布局，建议结合内容项数设为Math.min(6, optionCount)类似的逻辑 - 移动端 Safari 对大
size值支持不稳定，若选项超 8 个，建议降级为单选 + 搜索式自定义下拉
height 对单选 <select> 只影响按钮区，别指望它控下拉菜单高度
给单选 <select> 写 height: 40px，实际只缩放/拉伸顶部“选中区域”，点击后弹出的下拉列表高度完全不受影响——它由操作系统菜单策略决定（Windows 通常最多 10–12 行，macOS 更不可控）。
你看到的“高度变化”只是视觉欺骗：文字可能被压扁、边框错位、箭头偏移，但真正交互的弹层尺寸和滚动行为毫无改变。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
height+padding组合在 Firefox 中偶尔能微调视觉比例，但在 Chrome 120+ 会触发可访问性警告（Lighthouse 报 “form elements not scalable”） -
line-height对<select>完全无效，它是替换元素，浏览器直接忽略该声明 -
max-height、overflow-y对原生下拉弹层无作用，开发者工具里根本看不到它在 DOM 中
需要精确控制整体高度？只能放弃原生 <select>
当你必须满足以下任一条件时，原生 <select> 已经不是选项：固定弹层最大高度、自定义滚动条样式、键盘导航到第 20 个选项不卡顿、高对比模式下文字清晰可见。
此时唯一稳定路径是用 <div> + <button> + <ul> 模拟，并隐藏原生 <select>（opacity: 0; position: absolute）。
- 把
max-height和overflow-y: auto加在<ul>上，效果 100% 可控 - 必须实现
aria-expanded、aria-controls和键盘事件（ArrowDown/Escape）否则屏幕阅读器无法识别 - iOS Safari 要求触摸热区 ≥ 44×44px，强行压缩模拟按钮会导致点不中，别省这个 padding
- 别用
transform: scale()缩放原生<select>来“取巧”——它会让字体模糊、边框虚化，且 Chrome 120+ 明确标记为可访问性风险
引导项（如“请选择”）的高度陷阱
很多人给第一个 <option value="" disabled selected> 加 height 或 padding 想让它看起来更高，结果发现：该样式对 <option> 根本不生效，所有浏览器都无视。
这是底层限制：<option> 不是普通 HTML 元素，它的渲染由系统控件完成，CSS 无法穿透。
- 视觉上想突出引导项？只能靠文字内容（如加空格、emoji）或换用自定义下拉，在
<li>里自由设置padding和font-size - 如果坚持用原生，唯一能做的就是增大整个
<select>的height+padding，让文字在按钮区内垂直居中，但弹出菜单依然保持默认行高 - 注意：设了
required却又让value=""的引导项可提交，表单会静默通过——必须加disabled才能真正排除它
<select> 的高度控制本质是“管得了按钮，管不了菜单”。真要统一、稳定、可测，就得接受它是个黑盒，要么用 size 做有限妥协，要么亲手重写。 
