max-height对原生select完全无效，因其弹出菜单脱离文档流、由系统绘制；唯一跨浏览器有效的原生限高方案是html的size属性（如size="5"）；若需点击展开且精确控高，则必须用div+ul自定义下拉并完善可访问性。
max-height 对原生 select 元素完全无效——它控制不了展开后的弹出菜单高度，因为那个菜单根本不在文档流里，是操作系统或浏览器 UI 层绘制的独立窗口。
为什么直接给 select 设 max-height 或 height 没用
你写的 max-height: 200px 在 Chrome、Edge、Safari 中会被静默忽略；Lighthouse 会直接标记为“未生效样式”。原因很实在：select 的弹出层（popup）脱离 DOM，不响应任何 CSS 高度相关属性。你看到的“按钮区”可能被压扁，但点开后菜单仍按系统默认行高和项数渲染（通常是 8–12 行），滚动条位置、单行高度、是否出现滚动，全由 UA 决定。
- 给
option加height、line-height、padding—— 所有主流浏览器均忽略 -
appearance: none只能隐藏箭头，不开放对弹层的样式控制权 - iOS Safari 强制最小触摸热区为 44×44px，硬缩
select高度会导致点不中
唯一跨浏览器有效的原生方案：size 属性
size 是 HTML 原生属性，不是 CSS，它让 select 以多行列表形式常驻显示指定数量的选项，此时浏览器会据此计算初始高度并自动加滚动条。这是目前唯一不依赖 JS、无障碍支持好、全平台一致的限高方式。
-
size="5"→ 展开时固定显示 5 行，超出即滚动，无需 JS -
size="1"等效于默认下拉行为（但某些旧版 Safari 下可能丢失箭头） - 副作用：失去“点击展开”交互，视觉变成类似
textarea的列表控件 - 移动端 iOS Safari 可能无视
size，强制走全屏选择器
要保留点击展开 + 精确控高？必须自定义 div + ul
放弃原生 select，用语义化结构模拟，才能真正把高度控制权拿回来。关键不是“怎么写”，而是“在哪设”：
- 下拉容器（
ul）上设max-height: 200px和overflow-y: auto—— 这才是真生效的位置 - 每项（
li）可自由设padding、line-height、min-height，无兼容性问题 - 原生
select必须保留在 DOM 中（position: absolute; opacity: 0; pointer-events: none;），用于表单提交和屏幕阅读器识别 - 必须手动实现：
Escape关闭、ArrowDown/Up导航、Enter确认、外部点击收起、aria-expanded同步
别在错误的地方试错
有人给 select 加 transform: scale() 想“压矮”，结果文字模糊、热区偏移、Chrome 120+ 报可访问性警告；有人用 line-height 去撑开 option，连 Firefox 都不认。这些都不是 bug，是浏览器能力边界。真正需要统一单项高度、固定最大展开高度、支持键盘导航和屏幕阅读器的场景，自定义组件不是过度设计，而是不得不做的取舍——尤其当你的用户要靠键盘或读屏器操作时，那几行 ul 和 li 的语义与行为，比“看起来像原生”重要得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
