em不能用于select和option的height控制，因其为替换元素且渲染由系统处理；仅padding和font-size可用em，需配合transform:scale()补偿缩放，自定义下拉中em才真正生效。
em单位对
直接给 select 设 height: 2.5em 不起作用——这不是单位问题，而是浏览器根本不解析 height 对下拉菜单的控制意图。em 在这里和 px 一样被忽略，因为 select 是替换元素，其弹出层由系统绘制，CSS 高度属性无法穿透。
真正能用 em 的地方只有两个：一是 padding（比如 padding: 0.75em 1em），它能稳定撑开选中区并随字体缩放；二是 font-size（比如 font-size: 1.125em），配合 transform: scale() 补偿缩放后文字过小的问题。
-
padding用 em 更安全：当父容器字体变化时，内边距能等比缩放，避免文字贴边或留白过大 -
font-size用 em +transform: scale()组合时，需同步调整，否则文字会模糊或过小（例如原font-size: 1rem，缩放 y=0.8 后建议设为1.25em） - 别在
option上用 em 设height或line-height：所有浏览器均静默忽略，移动端尤其明显
为什么em不能绕过浏览器对
option 元素不接受任何高度相关 CSS，em、px、vh 全部失效。这不是单位精度问题，而是规范层面的限制：它的渲染交由操作系统控件（如 Windows 的 ComboBox、macOS 的 NSPopUpButton）处理，DOM 和样式层完全隔离。
你看到 DevTools 中 option { line-height: 2em } 被划掉，不是优先级低，是 UA 样式表根本没把它当作可样式化节点解析。
立即学习“前端免费学习笔记（深入）”；
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- iOS Safari 强制最小行高 ≈ 44px（与触摸热区绑定），哪怕你设
font-size: 0.5em，实际点击区域仍按 44px 计算 - Chrome/Edge 中
option的行高固定在 22–26px 区间，不受任何 CSS 影响 - 试图用
em实现“响应式行高”只会增加调试成本，无实际收益
用em做统一视觉高度时的实操要点
若表单中多个 select 需与 input[type="text"] 对齐，且整体字体基于 rem/em 动态缩放，可这样组合控制：
- 统一设
font-size: 1rem在根节点，再用em控制各控件内边距 -
select用padding: 0.625em 1em（即 10px/16px 基准），input用相同 padding，再配box-sizing: border-box - 隐藏原生箭头用
appearance: none+::after伪元素，背景尺寸也用em（如background-size: 1em 1em）保持缩放一致性 - 避免对
select单独设height：它会破坏 flex 容器中的align-items: center对齐逻辑，尤其在 Safari 中
真正需要em参与高度控制的场景，基本都指向自定义下拉
当你必须让每项 li 高度 = 2.25em、滚动容器最大高度 = 12em、悬停时上下留白 = 0.5em，说明已越过原生 select 的能力边界。此时 em 才真正生效，因为它作用于标准块级元素。
但要注意：自定义组件里用 em 的前提是字体继承链清晰。若 ul 被包裹在 font-size: 0.875em 的卡片内，那 li { height: 2.25em } 实际就是 2.25 × 0.875 × 16px ≈ 31.5px —— 这种级联必须手动验证，不能只看 DevTools 显示的计算值。
最容易被忽略的是：iOS Safari 在页面缩放（非用户手势，而是 meta viewport 缩放）下，em 计算可能跳变，建议在自定义下拉的 ul 上加 font-size: 1rem 锁定基准，再用子元素的 em 微调。
