原生 无法实现符合用户预期的多选下拉交互，因其渲染为固定高度列表框、依赖冷门快捷键、移动端支持差且样式不可控，必须用自定义组件替代。
HTML下拉框加 multiple 属性就能多选，但默认样式和交互很反直觉
直接加 multiple 属性确实启用多选，但浏览器不会把它渲染成“点击展开的下拉菜单”，而是变成一个固定高度的滚动列表框（），用户必须按住 Ctrl（Windows/Linux）或 Cmd（macOS）才能多选——这点绝大多数用户根本不知道，也完全不符合“下拉框”的心理预期。
为什么
移动端 Safari 和 Chrome 对 multiple 的支持极其有限：iOS 上点开后只允许单选，且不显示任何多选提示；Android 各厂商 WebView 行为不一，部分会忽略 multiple 直接当单选处理。更关键的是，原生 无法用 CSS 精确控制下拉区域样式，也无法绑定点击外部自动收起等基础交互。
- 不能用
:focus-within或 JS 模拟“点击空白处关闭” - 无法自定义选项勾选图标（如 ✅ 或复选框）
-
size属性强制显示行数，无法实现“点击才展开”的下拉动效
真正可用的多选下拉，得用自定义组件替代原生
主流方案是用 例如使用 立即学习“前端免费学习笔记（深入）”； 它会自动隐藏原生 仅限管理后台、内部工具等对用户要求极低的场景。必须手动增强可访问性和基础可用性： 原生多选下拉框的“多选”只是 HTML 层面的声明，实际体验是否可用，90% 取决于你有没有绕过它的限制做二次封装。别被 + JavaScript 模拟：把可见部分做成可点击的标签栏（显示已选项），点击后展开带 的选项列表。这样既能保留多选逻辑，又能控制样式、键盘导航和移动端触控反馈。
choices.js 库时，只需：
，生成一套可键盘操作（Tab/Arrow/Space）、支持搜索、带清空按钮的 UI，且在 iOS 和 Android 上行为一致。如果坚持用原生
，至少要补这些细节
aria-label 或 ，否则屏幕阅读器无法识别多选意图size="5" 设定可见行数（不能设为 1，否则退化为单选）change 事件时，用 Array.from(select.selectedOptions).map(o => o.value) 取值，别用 select.value（它只返回第一个选中项）autocomplete="off" —— 某些旧版 Edge 会因此阻止多选状态持久化multiple 这个单词骗了。
