原生<select>的height、max-height和line-height对下拉菜单无效，因其弹出层由系统绘制；仅能通过控制按钮区高度、使用size属性实现常驻列表、或完全自定义下拉来应对。
原生 <select> 的 height、max-height 和 line-height 对下拉弹出菜单完全无效——它由操作系统或浏览器 UI 层绘制，CSS 无法穿透。所谓“固定高度”，只能分三类场景处理：控制顶部按钮区视觉高度、限制常驻列表可见行数、或彻底自定义下拉。
为什么直接设 height 和 max-height 失效
浏览器把 <select> 拆成两个独立渲染层：<select> 本体（顶部选中区）可被部分 CSS 影响，但点击后弹出的菜单是系统级 UI 组件，脱离文档流。max-height 在 <select> 上会被忽略；<option> 上设 height 或 padding 所有主流浏览器均不响应；iOS Safari 尤其严格，连 font-size 缩放都可能被降级处理。
- Chrome/Edge 中
height: 40px只压扁按钮区，弹出菜单仍默认显示 8–10 行 - Firefox 略宽松，但依然无法控制弹出层滚动行为和项数
- 给
<select>加overflow: hidden不会裁剪弹出层，反而可能让桌面端菜单被父容器截断
用 size 属性实现真正可控的常驻高度
size 是唯一被所有浏览器一致支持的原生方案，它让 <select> 放弃弹出行为，转为固定行数的常驻列表，此时高度可被 CSS 稳定影响。
-
<select size="4">强制显示 4 行<option>，超出自动出现overflow-y: auto - 配合
height、padding、font-size可精确控制整体视觉高度（如padding: 10px 12px+font-size: 14px≈ 总高 40px） - 别混用
size="1"和multiple：前者在旧版 Safari 可能丢失箭头，后者会让语义变为多选列表 - 移动端慎用
size > 6，DOM 渲染负担明显上升，且长列表易误触
自定义下拉时，max-height 必须作用在 <ul> 上
当设计要求“点击展开 + 固定最大高度 + 自定义行高 + 滚动条样式”，必须用 <div> + <button> + <ul> 模拟。关键点不是“怎么写 CSS”，而是“写在哪”：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
-
<ul>必须设max-height: 200px+overflow-y: auto，这才是真生效的限高位置 -
<ul>上设height: 100%是安全的，前提是父容器（如<div class="custom-select">）没写死height或min-height - 每项
<li>用padding: 10px 12px或line-height: 36px控制单行高度，避免依赖 UA 默认值 - 必须加
position: absolute定位<ul>，并确保父容器有position: relative，否则下拉层错位
别碰 transform: scale() 除非只要视觉对齐
transform: scale(1, 0.8) 是最轻量的“统一外观”方案，但它不是控高，是视觉欺骗：
- 缩放同时影响文字、边框、箭头和点击热区，iOS Safari 要求触摸区 ≥ 44×44px，缩太小就点不中
- 必须补
transform-origin: top center和margin-top抵消上移偏移，不同字号下补偿值不一致 - Chrome 120+ 会报 “form elements not scalable”，高对比模式下文字可能模糊或失色
- 它对弹出菜单本身也缩放，可读性反而下降，且无法解决行高不一致问题
真正难的不是写哪行 CSS，而是接受：你永远不能用一行 max-height 命中那个弹出层——它根本不在你的样式作用域里。
