原生 的下拉层高度无法用 css 限制，因其是浏览器/操作系统绘制的独立 ui，不在 dom 中；唯一可控方案是用 + 等重建自定义组件，使下拉层成为普通 dom 元素。
原生 <select></select> 的下拉层高度根本不能用 CSS 限制
直接说结论：你给 <select></select> 设置 max-height、height、overflow-y，甚至 -webkit-appearance: none，对点击后弹出的下拉菜单（即“下拉层”）完全无效。这个弹出层是浏览器或操作系统绘制的独立 UI，不在 DOM 中，CSS 无法穿透。
常见错误现象包括：
- 开发者工具里看到
<select></select>元素被设置了height: 100px，但点开后仍显示 8–12 行，且自动加滚动条 - 给父容器加
max-height: 150px; overflow: hidden，结果下拉菜单被裁剪掉下半部分 - 在
<option></option>上写line-height或padding，毫无反应
size 属性只能模拟固定行数，不是真正“限制高度”
size 是 <select></select> 的 HTML 属性，例如 <select size="4"></select>，它会让下拉框**始终展开为 4 行可见选项**（类似多选列表），但这不是“下拉层高度限制”，而是切换了渲染模式——此时它不再弹出系统菜单，而是在页面内渲染为一个可滚动的块级区域。
使用场景有限：
- 仅适用于不需要点击触发、允许常驻展开的表单场景（如筛选器面板）
- 不支持自定义箭头、键盘导航（Tab/Arrow）行为与原生下拉不一致
- 移动端（尤其 iOS）可能降级为全屏选择器，
size失效 - 无法和
multiple以外的交互逻辑共存（比如单选 + 搜索）
真正能控制下拉层高度的唯一方式：JS 自定义组件
必须放弃原生 <select></select>，用 <div> + <code><button></button> + <ul></ul> 重建下拉结构。此时下拉层是普通 DOM，所有尺寸完全可控：
-
max-height+overflow-y: auto可精准控制可视区域高度 -
line-height、padding、font-size对每个<li>选项都生效 - 可通过
calc(5 * 36px)等动态值让高度随选项数弹性变化 - 配合
position: absolute和正确z-index，避免被父容器overflow: auto裁剪
关键注意点：
- 别只隐藏原生
<select></select>（opacity: 0），必须用aria-hidden="true"并同步管理焦点和键盘事件（ArrowDown/Escape） - 移动端需特别处理触摸热区（iOS 要求 ≥44×44px），强行缩小会导致点不中
- Chrome 120+ 对 transform 缩放后的自定义下拉会报可访问性警告，优先用原生尺寸+padding 调整
为什么很多人误以为“height 生效了”
给 <select></select> 设 height 看似改变了外观，其实只压扁了顶部“触发区域”（即未展开时的输入框部分），而下拉层高度依然由系统决定。这种错觉容易掩盖真实问题：
- 在 Firefox 中可能偶然看到一点效果（因 UA 样式略有不同），但换到 Chrome 或 Safari 就失效
- 用
transform: scale()缩放整个元素，会连文字、边框、点击热区一起缩，导致高对比模式下不可见或触控失败 - 依赖
appearance: none后手动画箭头，不代表获得了对下拉层的控制权——它只是藏起了原生图标
最常被忽略的点：所谓“下拉层高度”，本质上不是一个 CSS 可控的盒子，而是一个平台级 UI 行为。想控制它，就得接管它的整个生命周期。
