面包屑里嵌下拉菜单本质是结构嵌套问题，纯HTML仅负责语义化层级（如），CSS控制定位与显隐（position: relative/absolute、opacity+visibility过渡），JavaScript实现交互逻辑（焦点管理、ESC关闭、键盘导航、外部点击收起），并严格遵循可访问性规范（aria-current、aria-expanded、role="menu"等）。
面包屑里嵌下拉菜单，本质是结构嵌套问题
纯 HTML 无法实现“点击面包屑某一项弹出下拉”的交互，必须配合 CSS 和 JavaScript。所谓“HTML 做面包屑下拉”，其实是用 <nav></nav> + <ol></ol> 或 <ul></ul> 搭建语义化层级，再用 CSS 控制显示/隐藏，JS 绑定点击事件——HTML 只负责结构，不是功能主体。
常见错误是直接在 <li> 里硬塞 <select></select> 或用 <details></details> 粗暴替代，结果语义错乱、键盘不可访问、移动端点不灵。
- 面包屑应使用
<nav aria-label="Breadcrumb"></nav>包裹，每项用<li>，当前页加aria-current="page" - 下拉内容建议放在对应
<li>内部，用<div role="menu"> 或 <code><ul class="dropdown-menu"></ul>，避免脱离 DOM 层级 - 不要用
<select></select>模拟下拉：它天生是表单控件，语义不符，且无法自定义样式或支持图文项 - 父
<li>设position: relative，下拉容器设position: absolute+top: 100% - 用
opacity: 0+visibility: hidden配合transition，比单纯display: none更利于动画和可访问性 - 务必加
min-width: max-content，防止下拉项文字被截断或换行错乱 - 移动端需监听
touchstart并阻止默认行为，否则点击会触发两次（touch + click） - 点击非下拉区域时，用
event.target.closest('.breadcrumb-item')判断是否点在面包屑项上，而不是监听整个document - 每次展开前，先关闭其他已开的下拉（避免多开堆叠），用
querySelectorAll('.dropdown-open')清理 - 给下拉容器加
role="menu"，子项加role="menuitem"，并用tabindex="0"支持键盘聚焦 - 按 ESC 键时，焦点应回到触发它的面包屑文字链接上，而不是丢失
- 避免在
v-for或.map()中直接写内联@click="open = !open"：状态分散，多个下拉互相干扰 - 下拉数据建议通过
props传入数组，而非在组件内硬编码fetch，方便测试和 mock - SSR 场景下，初始渲染时下拉必须为关闭态（
aria-expanded="false"），否则 hydration 会冲突
CSS 控制下拉显隐的关键点
靠 :hover 实现桌面端展开最轻量，但手机端无效；靠 JS 切换 aria-expanded 和 class 才真正可用。CSS 必须满足三点：定位不破坏流式布局、z-index 足够高、过渡自然。
JavaScript 绑定点击时容易漏掉的细节
只写 element.addEventListener('click', toggle) 不够。真实场景中要处理焦点管理、ESC 关闭、外部点击收起、键盘导航（Tab / ArrowDown / Enter）——否则屏幕阅读器用户根本用不了。
立即学习“前端免费学习笔记（深入）”；
Vue/React 项目里别重复造轮子
如果用 Vue，<el-breadcrumb></el-breadcrumb>（Element Plus）本身不支持下拉，但可以封装一个 BreadcrumbDropdown 组件，把下拉逻辑收敛在 useDropdown 自定义 Hook 里；React 中推荐用 @headlessui/react 的 Menu 组合 Breadcrumb，而非手写 useState 控制显隐。
最常被忽略的是焦点顺序和屏幕阅读器 announce——哪怕视觉上完美，若没正确设置 aria-haspopup、aria-controls 和动态 aria-live，对辅助技术用户就是不可用的。动手前先跑一遍 Lighthouse 的 Accessibility 审计。
