应优先使用原生select而非自定义下拉组件，因其天然支持键盘导航、屏幕阅读器识别、表单自动序列化及跨浏览器一致性；若需定制，details是更可靠的折中方案。
select 是最轻量、语义正确且无障碍友好的下拉实现方式，只要不强求自定义箭头或字体渐变，就别绕开它去手写 div+ul。
为什么直接用 select 而不是自己封装 dropdown 组件
多数“看起来更酷”的自定义下拉菜单，实际牺牲了键盘导航、屏幕阅读器识别、表单自动序列化等基础能力。原生 select 天然支持 Tab 切换、方向键滚动、Space/Enter 展开，且在所有主流浏览器中行为一致。手写组件若没补全 aria-expanded、aria-haspopup、焦点管理与 role="listbox" 等逻辑，反而会让残障用户无法操作。
- 表单提交时，
select的name和选中value会自动打包进FormData，手写组件需手动同步 - 移动端 iOS Safari 对
select的触摸反馈和键盘联动已深度优化，而 JS 模拟菜单常出现点击无响应或输入法冲突 - 禁用状态只需加
disabled属性，CSS 的pointer-events: none或opacity: 0.5不会真正阻止聚焦或键盘交互
select 样式定制的硬性边界
Chrome/Firefox 允许改 padding、border、font-size，但 Safari（尤其 macOS）对 appearance: none 支持不稳定，伪元素如 ::-webkit-appearance 在新版中已被弃用。强行覆盖箭头极易导致文字截断或下拉面板错位。
- 必须用
padding-right预留图标空间，否则text-overflow: ellipsis或长文本会被遮挡 - 不要设
height+line-height组合——Safari 会把下拉箭头压进文字行高里，造成视觉错位 -
overflow: hidden在 macOS Chrome 下会裁剪弹出的选项面板，禁用 - IE11 不支持
appearance，若还需兼容，得用filter: alpha(opacity=0)配合绝对定位图层盖住原生箭头
动态操作 select 时容易漏掉的同步点
JS 修改 select 选项后，UI 和 DOM 状态常不同步：比如用 innerHTML 批量重写 option，会导致当前焦点丢失；用 value = "xxx" 设值，若对应 option 不存在，界面不会更新但 value 已变。
立即学习“前端免费学习笔记（深入）”；
- 新增选项统一用
selectElement.add(new Option("文本", "值"))，比innerHTML +=安全，不触发重排且保留焦点 - 设默认选中项优先用
selectElement.value = "xxx"，而非遍历options手动设selected属性 - 读取显示文本用
selectElement.options[selectElement.selectedIndex].text，别只依赖value——用户看到的和提交的可能是两套值 - 禁用某选项用
option.disabled = true，注意这不影响select.value读取，只是交互限制
当真需要视觉定制时，details 是比手写更稳的折中方案
details 是 HTML5 原生展开组件，无需 JS 就能切换显隐，键盘支持完备（Space/Enter 展开、Tab 导航），Edge 79+、Chrome 12+、Firefox 49+、Safari 6.2+ 全支持。它比 select 更易样式化，又比手写组件更可靠。
- 用
summary::marker { content: "▼"; }替换默认三角，避免 Safari 不支持list-style - 给
summary加padding扩大点击区域，但别设display: block——会破坏原生焦点行为 - 不支持多级嵌套：
details内再套details在部分 Android WebView 中会失效 - 移动端要监听
touchstart而非click，避开 iOS Safari 的 300ms 延迟
真正难的不是让下拉“动起来”，而是让它在键盘、屏幕阅读器、缩放模式、弱网环境、旧浏览器里都保持可用。原生控件的约束，其实是对用户基本操作权的保障。
