Custom Elements 不适合构建常规导航菜单，因其引入复杂度、可访问性风险和兼容性问题；仅当需跨框架复用、动态状态管理或多级键盘导航等组件库级需求时才适用。
HTML 自定义元素（Custom Elements）不适合用来构建常规导航菜单——它会引入不必要的复杂度、可访问性风险和兼容性问题，除非你正在开发一个需要高度复用、跨框架集成的「组件库级」菜单系统。
为什么 Custom Elements 不该用于普通导航菜单
自定义元素本质是 Web Components 的一部分，设计目标是封装可复用、带状态和生命周期的 UI 单元。但导航菜单的核心需求是语义清晰、键盘可聚焦、屏幕阅读器可识别、SEO 友好，这些靠 <nav> + <ul> + <li> + <a> 就能原生满足。用 class="my-nav-menu" 或 define("nav-menu") 去替代，反而会：
- 丢失
<nav>的语义容器作用：读屏软件无法自动识别这是“主导航”，必须手动加aria-label且挂载位置难保证 - 破坏
Tab键顺序：自定义元素默认tabindex="-1"，需显式设tabindex="0"并监听keydown处理方向键，而原生<a>天然支持 - 增加 JS 依赖：哪怕只做静态菜单，也得注册元素、等待
customElements.define()完成，首屏渲染延迟且 SSR 不友好 - 绕过浏览器对
<ul><li><a>的内置焦点管理逻辑，比如:focus-visible行为可能异常
什么场景下才值得用 Custom Elements 做菜单
只有当你的菜单具备以下至少两项特征时，才考虑封装为自定义元素：
- 需要在 React/Vue/Angular 项目中统一接入，且不希望每个框架都写一遍逻辑
- 菜单数据来自远程 API，且需内置 loading/error/retry 状态管理
- 支持多级动态展开，并要求动画同步、焦点自动跳转、键盘导航（↑↓←→Esc）全链路控制
- 要内建权限过滤逻辑（例如根据用户角色实时隐藏某些
<li>），且该逻辑需与后端 token 绑定
此时，你可以定义 <smart-nav>，但内部仍必须用 <nav> 包裹标准结构，例如：
立即学习“前端免费学习笔记（深入）”；
<smart-nav data-api="/menu.json">
<nav aria-label="主导航">
<ul></ul>
</nav>
</smart-nav>
注意：<ul> 和子 <li> 必须由 JS 动态注入到 shadow DOM 外部的 light DOM 中（或使用 slot 投影），否则屏幕阅读器不可见。
性能陷阱：Shadow DOM 与导航菜单的冲突
如果你把整个菜单塞进 Shadow DOM（例如 this.attachShadow({mode: 'open'})），会导致：
- 所有 CSS 需重复定义，无法继承页面全局样式（如字体、链接颜色）
-
:hover和:focus在部分旧版 Safari 中失效，尤其嵌套层级深时 - 父页面无法用
document.querySelector('a[href="/about"]')直接获取链接，影响分析脚本或自动化测试 - 键盘 Tab 进入 Shadow DOM 后，可能卡在第一个元素，无法自然流转到下一个
<a>
解决办法只有一个：不要把 <a> 放进 Shadow DOM。让自定义元素只负责数据加载和状态分发，真实 DOM 结构保留在 light DOM 中。
替代方案：用原生语义结构 + 模块化 CSS/JS
95% 的项目更适合用以下组合实现「高性能」与「可维护性」：
- HTML 结构保持朴素：
<nav aria-label="主导航"><ul><li><a href="/home">首页</a></li></ul></nav></li> <li>用 CSS 自定义属性（<code>--nav-bg
,--nav-link-padding）统一主题，避免重复类名 - 下拉菜单用
<input type="checkbox">+:checked ~ ul实现零 JS 展开（iOS Safari 15.4+ 安全） - 响应式切换用媒体查询 +
display: flex/flex-direction: column，而非 JS 控制 class
真正影响性能的从来不是标签名字，而是是否触发重排、是否阻塞渲染、是否让辅助技术失效——这些，<nav> 比 <my-nav> 更可靠。
