size属性设了却没变高，是因为它不控制高度而是切换控件类型：size≥2时转为多行列表，但实际显示受浏览器支持（safari/ios忽略size>1）、css覆盖及值合法性影响。
size属性为什么设了却没变高
因为size不是“调高度”，而是切换控件类型：设为2或更大时，select就从下拉模式强制变成固定行数的列表控件。但它是否真显示成你想要的“4行”，取决于三件事：
- 浏览器是否真正支持该
size值（Chrome/Edge 基本 OK，Safari 在 iOS 上直接忽略size>1） - CSS 是否意外覆盖了默认行高或高度计算（比如重置库里写了
select { height: auto; }） -
size值是否为正整数（size="0"、size=""、size="-1"全无效，退化为size="1"）
用 DevTools 检查 computed 样式里的 height 和 line-height，如果发现实际高度远小于预期，大概率是 CSS 重置或浏览器兜底逻辑在起作用。
Chrome/Firefox 里 size 生效但 Safari 不认
iOS Safari（含微信、QQ 内置浏览器）对size属性有硬性限制：只要值大于 1，就静默忽略，强制回退到单行下拉。这不是 bug，是 WebKit 的设计策略——它认为移动端应统一用原生选择器弹窗。
这意味着：
- 你在桌面 Chrome 调好
<select size="5"></select>，iPhone 上打开就是个普通点击展开的下拉框 - JS 动态设置
select.size = 4在 iOS 里也无效，DOM 属性虽写入成功，但渲染不响应 - 没有 CSS 或 polyfill 能绕过这个限制；想在 iOS 上实现多行可见，必须换方案
如果你的用户主力在微信里访问，size 就不是“可用不可用”的问题，而是“根本不能依赖”。
height / line-height 对 select 下拉菜单完全无效
height CSS 属性只可能影响 select 的顶部选中区域（即你看到的那个按钮），但对点击后弹出的下拉菜单（popup）零作用。这个弹层由操作系统或浏览器 UI 框架绘制，CSS 无法穿透。
常见误操作和后果：
- 写
select { height: 50px; line-height: 50px; }→ 顶部区域被拉高，文字垂直居中异常，弹出菜单仍按默认行高显示 8–10 行 - 加
appearance: none→ 只能隐藏原生箭头，不改变弹层渲染逻辑 - 用
transform: scale()缩放 → 整体变小，但 iOS 高对比模式下可能文字消失，Lighthouse 会报可访问性警告
真正可控的只有两件事：顶部区域样式（有限）、或彻底放弃原生 select 自己用 <div>+<code><ul></ul> 实现。
真正能落地的两种轻量方案
不引入 React/Vue 组件库，也能解决“要高度可控+跨端一致”的需求：
-
轻度增强（适合桌面为主）：用
size+ 精确的font-size+padding控制视觉高度，再加媒体查询适配移动端回退为size="1"，并提示“点击展开” -
自定义下拉（必须跨端）：用
<button aria-expanded="false"></button>+<ul role="listbox"></ul>，配合 JS 控制显隐和键盘导航（ArrowDown/Enter/Escape），所有尺寸、滚动、焦点管理完全自由
最常被忽略的一点：哪怕用了自定义下拉，aria-activedescendant 和 tabindex 的配合稍有偏差，屏幕阅读器就会读错当前选项——这不是“看起来像就行”，而是语义链断裂就等于不可用。
