原生 select 的下拉菜单高度无法通过 CSS 控制，因弹出层由系统 UI 渲染；唯一跨浏览器有效的限高方案是 HTML 的 size 属性，或彻底自定义 div+ul 结构实现精确控制。
原生 select 的下拉弹出菜单高度无法用 height、max-height 或 line-height 控制——这不是写法问题，而是浏览器和操作系统的底层限制。你调了没反应，不是 CSS 写错了，是它根本穿不透。
为什么 height 和 max-height 在 select 上基本失效
浏览器把 select 拆成两部分：顶部可点击的“选中区”（CSS 可有限干预）和独立绘制的“弹出菜单”（由系统 UI 层渲染，CSS 完全不可控）。你给 select 设 height: 36px，只压扁按钮区；点开后仍显示 8–12 行默认高度的选项，滚动条位置、行高、项数全不受影响。
-
max-height在select元素上会被浏览器直接忽略，Lighthouse 会标记为“未生效样式” -
line-height对select本身无效，因为它是替换元素（replaced element），不参与 CSS 行盒布局 -
option元素几乎不响应任何高度相关 CSS：height、padding、margin在 Chrome / Edge / Safari / iOS / Android 上均被忽略 - iOS Safari 强制最小触摸热区为 44×44px，强行缩到 32px 就可能点不中
size 属性是唯一跨浏览器有效的原生限高方案
size 是 HTML 原生属性，不是 CSS，它让 select 以“常驻列表”模式展开并固定显示指定行数。此时浏览器会按行数 × 默认行高计算弹出区域高度，并自动加滚动条——这才是真正可控、无 JS、全平台一致的行为。
-
size="4"→ 展开时显示 4 行选项，超出即滚动；size="1"等效于默认单选下拉（但旧版 Safari 可能丢失箭头） - 必须搭配
multiple才能多选，但语义仍是单值提交（除非后端明确接收数组） - 副作用：失去“点击才展开”的交互直觉，渲染为多行控件；移动端易误触，长列表（>6 行）DOM 渲染负担上升
- 不能和
max-height混用——size决定的是可见行数，不是像素高度
要保留“点击展开” + 精确控高？只能自定义 div+ul
当设计要求明确包含“最大高度 200px、每项 40px 高、支持滚动条样式、hover 高亮、键盘导航”，就必须放弃原生 select。核心是隐藏真实 select，用语义化结构模拟交互，并同步值与状态。
立即学习“前端免费学习笔记（深入）”；
- 父容器设
position: relative，下拉层（ul）用position: absolute; top: 100%定位 -
ul上设max-height: 200px; overflow-y: auto—— 这才是真生效的限高 - 每个
li可自由设height、line-height、padding，文字垂直居中推荐display: flex; align-items: center - 必须监听：
click外部关闭、Escape键收起、ArrowDown/Up导航、Enter确认，否则键盘和屏幕阅读器不可用 - 无障碍关键：
select保留在 DOM 中（position: absolute; opacity: 0; pointer-events: none），同步更新其value并维护aria-expanded、aria-controls、aria-activedescendant
别踩这些兼容性与可访问性坑
很多“看似生效”的写法在真实环境里会掉链子。比如 transform: scale(1, 0.8) 虽能视觉压缩 select，但弹出菜单仍按原始尺寸展开；又比如 appearance: none 只能隐藏箭头，对弹层毫无影响。
- Chrome 120+ 对缩放表单控件会报可访问性警告：“form elements not scalable”
- iOS Safari 对
size属性支持薄弱，常强制走全屏选择器，size="4"可能完全被无视 - Windows 高对比模式下，自定义下拉若没设显式
color和background，可能整片空白 - 移动端需额外处理
touchstart和focus同步，iOS Safari 对focus触发极不敏感 - 选项超 30 条时，必须加虚拟滚动或搜索过滤，否则卡顿明显——原生
select不会卡，但自定义组件会
真正需要精确控制下拉高度时，核心不是“怎么写 CSS”，而是接受一个事实：原生 select 的弹出层是黑盒。你能在 size 的妥协和自定义的投入之间做选择，但没法绕过这个边界。
