最稳方案是原生 select + change 事件：value 与内容区 id 一致，用 document.getElementById() 获取；多控件时用父容器结构定位；自定义下拉须补全 ARIA 和键盘逻辑；iOS 上应接受原生 select 或完整实现可访问性。

用 select + change 事件动态切换内容区域最稳

原生 select 元素配合 change 事件是实现“选一项、显一块内容”的最轻量且兼容性最好的方案。它不依赖框架，天然支持键盘导航（Tab + 方向键）、屏幕阅读器，也不会因事件冒泡错乱导致菜单闪闭。

关键在于让每个 option 的 value 和对应内容容器的 id 完全一致：

• value="Gradients" → 内容区
• value="Custom Color" → 内容区
  （注意：含空格的 id 合法但需在 JS 中用引号包裹）

  监听时直接取 event.target.value，再用 document.getElementById() 找目标元素，比遍历 class 或靠 data 属性更可靠。别忘了初始隐藏所有内容区，只显示默认项对应的那个。

  多个独立下拉菜单共存时，别用重复 id，改用 DOM 关系定位

  当你有“国家选择”“城市选择”“邮编输入”三个下拉控件并列时，如果都写 id="dropdown"，document.getElementById("dropdown") 永远只返回第一个——这是绝大多数“点A却展开B”的根源。

  正确做法是放弃全局 id 查找，改用结构绑定：

  • 把每个下拉按钮和它的内容区包进同一个父容器，比如
  • 点击按钮时，用 event.currentTarget.parentElement.querySelector(".dropdown-content") 精准拿到它自己的内容区
  • 避免用 getElementsByClassName 返回类数组，它不响应实时 DOM 变化；优先用 querySelector 或 closest() 向上找最近父级

  这样哪怕页面有 20 个下拉菜单，也不需要写 20 个不同 id，代码可复制、易维护。

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

  自定义下拉（非 select）必须补全 ARIA 和键盘逻辑

  如果你因为样式或交互需求，用

  +

  手写一个下拉菜单，那它就不再是语义化控件——浏览器不会自动识别它是“可展开的组合框”，键盘用户按 Tab 进不来，屏幕阅读器读不出当前状态。

  至少要加这些：

  • role="combobox" 在触发按钮上
  • aria-expanded="false" 初始值，点击后同步更新为 "true" 或 "false"
  • aria-controls="content-id" 指向内容区的 id
  • 手动监听 keydown：Enter/Space 展开，Escape 收起，方向键上下移动焦点

  漏掉任意一条，都可能让残障用户完全无法操作。别信“加个 tabindex 就行了”——那只是让元素能被聚焦，不是让它变成可访问的下拉控件。

  移动端 iOS Safari 对 select 的限制比你想象中多

  iOS 上的 select 点击后弹出的是全屏原生选择器，CSS 几乎无法定制外观；而你写的下拉动画、定位、箭头图标，在那里根本看不到。

  如果你强求视觉统一，有两个现实选项：

  • 彻底放弃原生 select，用自定义组件，但必须实现完整 ARIA + 键盘逻辑（见上一条）
  • 接受平台差异：PC/Mac 上用美化版，iOS 上降级回原生 select，用 @supports (-webkit-appearance: none) 做 CSS 特性检测来分流

  别试图用 appearance: none + 伪元素强行覆盖 iOS 的下拉指示器——它不生效，且可能破坏焦点链。真正在意体验的团队，都会把 iOS 当作独立适配场景来对待。