直接设 height 不行，因 select 是黑盒控件，height 仅影响按钮区，无法改变原生下拉弹层；可靠方案是用 padding 扩大热区、label 包裹增加点击范围、transform 缩放控件（需修正错位）。

为什么直接设 height 不行

浏览器把 <select></select> 当作一个“黑盒控件”：顶部可见区域勉强响应 height，但点击触发的下拉弹层（popup）由系统或 UA 原生绘制，CSS 完全穿不透。你设了 height: 48px，可能只撑开了按钮区，弹出菜单的行高、项数、滚动条位置照旧——用户真正要点击的选项区域根本没变大。

• Chrome / Edge（Chromium 内核）下 height 对弹层高度零影响
• Safari 对 height 和 padding 的响应最保守，常直接忽略
• line-height 对 <select></select> 无效，它是替换元素，不走常规行盒布局

真正能扩大点击热区的三个实操方法

不是所有“看起来更大”的方案都等于“更容易点中”，尤其要考虑移动端最小触控尺寸（iOS 要求 ≥ 44×44px）和高对比模式下的可访问性。

• 用 padding 推开文字，间接增大可点击范围：

  select { padding: 12px 16px; font-size: 16px; }

  这比单纯调 height 更可靠，且各浏览器兼容性好

• 给 <select></select> 外层加 label 并设 display: block，点击 label 文字/空白区也能聚焦：

  

  DeepBI DHTML 页面生成器

  生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur

  下载

  立即学习“前端免费学习笔记（深入）”；

  <label><select>...</select></label>

  配合 label { min-height: 44px; display: block; }，热区立刻达标

• 用 transform: scale(1, 1.2) 纵向拉伸整个控件（含弹层触发区）：

  select { transform: scale(1, 1.2); transform-origin: top center; margin-bottom: -2px; }

  注意：必须补 margin-bottom 抵消缩放导致的错位，且要同步微调 font-size 防止文字糊

自定义下拉时如何控制弹出层高度

一旦放弃原生 <select></select>，改用 <div>+<button>+<ul> 模拟，点击区域就完全可控：<ul> <li>弹出层（<code><ul></ul>）设 max-height: 240px + overflow-y: auto，保证内容多时不撑爆页面

每个 <li> 项用 padding: 10px 16px 明确定义点击热区，别依赖默认行高

必须加 role="listbox" 和 role="option"，否则屏幕阅读器无法识别“这是可点击列表”

移动端需在 touchstart 上调 event.preventDefault()，避免 300ms 延迟导致点不中

容易被忽略的兼容性雷区

• iOS Safari 会强制将 <select></select> 触摸热区限制在最小 44×44px，哪怕你 CSS 设成 30px，实际响应区仍是 44px——但视觉上还是小的，用户会困惑“明明看着小，怎么点得中？”
• Windows 高对比模式下，如果自定义下拉没设 color 和 background 的明确值，整个菜单可能变成透明或纯黑，完全不可见
• Chrome 120+ 对 transform 缩放后的表单控件会报 Lighthouse 可访问性警告：“form elements not scaled consistently”，需配合 aria-label 补偿

原生 <select></select> 的点击区域不是靠“调高”解决的，而是靠“推远文字”“包大容器”“换结构”三类动作组合落地。真要大面积、高精度控制，就得接受：弹层不是样式问题，是 DOM 结构问题。