移动端原生选择器仅在用户点击<select>元素（含padding区域）或JS在用户手势上下文中调用focus()时触发，且元素未被display:none、pointer-events:none等CSS属性阻断；iOS Safari忽略multiple和size属性，始终以单选弹窗形式打开，change事件仅在弹窗关闭后触发，Android各浏览器兼容性差异大，需真机测试。
移动端原生选择器什么时候会弹出来
不是所有 <select> 都会触发系统级选择器——它取决于是否被浏览器识别为“可交互的表单控件”，且未被 CSS 或 JS 干扰。iOS Safari 和 Android Chrome 的触发逻辑差异很大，但共性是：只有聚焦（focus）时才可能唤起原生 UI。
常见触发场景包括：
- 用户点击
<select>元素本身（含 padding 区域），且该元素未被pointer-events: none或disabled阻断 - JS 主动调用
selectElement.focus()（注意：iOS Safari 对 programmatic focus 有严格限制，需在用户手势上下文中执行） - 表单内其他控件失焦后，
<select>自动获得焦点（如按 Tab 键切换，但移动端无 Tab 支持，基本不生效）
不会触发的情况更值得警惕：
-
<select>被display: none、visibility: hidden或opacity: 0隐藏（哪怕只是临时） - 父容器设置了
transform或will-change，某些安卓 WebView 会跳过原生渲染路径 - 使用了
appearance: none+ 自定义下拉箭头但没保留原生交互区域（箭头点击区域未透传到<select>）
iOS Safari 的 select 行为特殊在哪
iOS Safari 根本不认 multiple 属性——它永远以单选弹窗形式打开，且不支持长按/多点触控来模拟 Ctrl+Click。这不是 bug，是 Apple 明确的设计决策：把多选交互交给开发者自己实现。
立即学习“前端免费学习笔记（深入）”；
这意味着：
-
<select multiple>在 iOS 上和<select>表现完全一致，选完就关闭，只提交第一个值 - 你无法靠 CSS 或 JS 强制它显示多选界面；
size属性也无效，iOS 忽略它 - 如果业务必须支持多选，别指望 iOS 原生行为，得用
<input type="checkbox">组合 + 展开/收起控制，或引入 tom-select 这类库（它们内部也是模拟 DOM，非真<select>）
一个典型坑点：change 事件在 iOS 上只在用户确认选择后触发（即弹窗关闭时），不像桌面端那样点即触发。所以别依赖“点一下就立刻更新状态”的逻辑。
Android 各厂商浏览器的兼容性现实
Android 端没有统一标准，Chrome、Samsung Internet、Firefox、甚至各 OEM 定制浏览器对 <select> 的处理各不相同：
- Chrome（较新版本）：支持
multiple，但多选弹窗无取消按钮，用户只能重选；size属性部分生效，但滚动条样式不可控 - Samsung Internet：有时会绕过原生选择器，直接渲染为带滚动条的列表（类似桌面），导致
change触发时机混乱 - 旧版 WebView（尤其 Android 7~9）：可能完全忽略
required校验，或把空<option value="">当作有效选项提交
关键结论：不要写死“Android 就能多选”。真实测试必须覆盖至少三台不同品牌真机（华为、小米、三星），不能只信模拟器。
如何判断当前设备是否真调起了原生选择器
没有 API 能直接检测“原生选择器是否已弹出”，但可通过间接方式观察行为特征：
- 监听
blur事件：iOS Safari 中，弹窗打开瞬间会触发blur，关闭后才再触发一次；而桌面 Chrome 是点击后立即 blur，选完再 focus 回来 - 检查
document.activeElement：弹窗期间，activeElement通常是body或null（因为焦点被系统接管），而非你的<select> - 用
setTimeout(() => console.log(document.activeElement), 0)在click后快速抓取——如果仍是<select>，说明原生 UI 没起来，大概率被 CSS 或 JS 阻塞了
最稳妥的做法，是把“是否启用原生选择器”当成不可控变量，所有交互逻辑都基于最终提交值做校验，而不是依赖中间状态。
