原生 select 的 line-height 无效是常态，因其为替换元素，内部渲染由系统控制，CSS 行高无法穿透；Chrome、Edge、Safari 均忽略，Firefox 行为不一致；可靠方案是用 padding + height 控制选中区视觉高度，或改用自定义 div+ul 组件实现可控下拉项行高。
原生 select 的 line-height 无效是常态，不是你写错了
直接给 select 或 option 设 line-height，浏览器基本无视。因为 select 是替换元素（replaced element），内部渲染由操作系统或 UA 样式控制，CSS 的 line-height 根本穿不进去。Chrome、Edge、Safari 全部跳过；Firefox 虽然在某些版本里能有限干预，但行为不一致，上线后容易翻车。
常见错误现象包括：
- 写了
line-height: 40px，但下拉项文字依然挤在顶部或上下留白奇怪 - 用开发者工具检查，发现该样式被标记为“已禁用”或“未生效”
- 不同浏览器下拉项高度明显不一致（比如 Chrome 显示 8 行，Firefox 显示 10 行）
padding + height 是唯一轻量且跨浏览器可控的方案
想让下拉框“看起来”行高更舒展，又不想引入 JS 库，就只能操作 select 本身的可样式化区域（即顶部选中区），而非不可控的弹出菜单。关键不是调“下拉项行高”，而是调“选中区视觉高度”并保持文字居中。
- 用
padding: 10px 12px比单纯设height更可靠——它同时撑开容器、推动文字垂直居中 - 若需精确高度，组合使用：
height: 40px; box-sizing: border-box; padding: 10px 12px - 避免只设
height：Chrome 下可能压扁边框或裁剪文字，Safari 可能完全忽略 -
appearance: none可隐藏原生箭头，但**不影响弹出菜单的行高**，别指望它解锁option样式
真要控制下拉项本身的高度？必须放弃 select，用 div+ul 模拟
当你需要统一每项的像素级高度（比如固定 48px/项）、支持多行文本、图标混排、或滚动区域限高时，原生 select 已经到头了。此时唯一路径是自定义组件，核心在于把控制权从系统拿回来。
立即学习“前端免费学习笔记（深入）”；
- 下拉层（
ul）设max-height: 200px; overflow-y: auto—— 这才是真正生效的限高 - 每个选项用
li包裹，可自由设height、line-height、padding，甚至display: flex - 必须手动实现键盘导航：
ArrowDown/ArrowUp切换焦点，Enter确认，Escape关闭 - 无障碍不能省：
aria-expanded、aria-controls、role="listbox"、role="option"全得配齐
移动端和高对比模式下最容易被忽略的坑
自定义下拉看似自由，但实际部署时几个硬性限制常被漏掉：
- iOS Safari 对触摸热区有最小尺寸要求（约 44×44px），强行把
li高度设成 32px，用户点不中 - Windows 高对比模式下，若
ul没设明确background-color和color，整个下拉菜单可能变成一片透明或纯黑 - Chrome 120+ 对 transform 缩放后的表单类交互元素会报 Lighthouse 错误：“form elements not scalable”，影响 SEO 和可访问性评分
- 动态渲染时（如 Vue/React 中 v-for 渲染），别忘了给每个
li绑定唯一key和tabindex="-1"，否则键盘导航会乱序
