多级菜单必须用 包裹，每个独立导航区域单独使用 并加 aria-label 区分；子菜单用 而非嵌套 保持结构扁平；菜单项当前状态用 aria-current="page" 标注在 上；js 锚点统一用 data-module 而非 class 或 id。

多级菜单必须用 <nav></nav> 包裹，不能只靠 div + class

浏览器、屏幕阅读器和搜索引擎都依赖 <nav></nav> 的语义识别导航区域。写成 <div class="menu">...</div>，JS 查询时 document.querySelector('.menu') 可能命中侧边栏、弹窗或旧代码残留的同名 class；而 document.querySelector('nav') 或 document.querySelector('[data-module="main-nav"]') 才稳定可靠。

常见错误现象：无障碍检测工具（如 axe）报「Missing landmark」；SEO 工具提示「Navigation not identified」；新同事改完菜单样式后，JS 动态展开逻辑突然失效——因为原逻辑绑定在 .nav-container 上，结果页面里有三个同名 class。

• 每个独立导航区域（主菜单、页脚链接、移动端抽屉）都应单独用一个 <nav></nav>，不要复用同一个容器
• 若页面含多个导航，给 <nav></nav> 加 aria-label 区分，例如 <nav aria-label="主导航"></nav> 和 <nav aria-label="页脚导航"></nav>
• 禁止嵌套 <nav></nav> 在 <header></header> 里再套一层 <div class="nav-wrapper">——<code><nav></nav> 自带语义和默认可访问性，额外包裹纯属冗余

  <ul></ul> 嵌套层级超过三层就该重构

  多级菜单常写成 <ul><li><ul><li><ul><li>...</li></ul></li></ul></li></ul>，DOM 深度达 6–7 层。这不仅拖慢 querySelectorAll('nav ul li a') 查询速度，更让审查元素时需要反复点击展开才能定位目标链接。

  性能影响明显：Chrome DevTools 的 Rendering 面板中，Layout 时间随嵌套深度非线性上升；协作时，后端模板渲染出错，往往卡在第 4 层 <ul></ul> 缺少闭合标签，但肉眼几乎无法发现。

  

  Doc To HTML

  使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

  下载
  • 视觉上“三级菜单”不等于 HTML 必须嵌套三层 <ul></ul>；可用 data-depth="2" 控制展开逻辑，HTML 保持扁平
  • 推荐结构：<nav data-module="main-nav"><ul><li>@#@#@#@#@#@#@#@#@#@0<div data-submenu="products"><ul><li>@#@#@#@#@#@#@#@#@#@1</li></ul></div> </li></ul></nav>
  • 所有子菜单用 <div> 容纳，而非继续 <code><ul></ul> 嵌套；CSS 用 nav [data-submenu] ul 控制样式，JS 用 nav.querySelectorAll('[data-submenu]') 绑定事件

    菜单项状态必须用 aria-current，别只靠 class="active"

    class="active" 是样式钩子，不是语义声明。当设计师把「当前页高亮色」从蓝色改成紫色，没人敢删这个 class——怕 JS 动画逻辑崩掉；但 aria-current="page" 明确告诉辅助技术“这是当前页面链接”，且不影响样式或 JS。

    容易踩的坑：用 aria-selected="true" 替代 aria-current；或给整个 <li> 加 aria-current，而不是直接加在 @#@#@#@#@#@#@#@#@#@2

  • 禁用 role="menuitem" 和 role="menu"：这些 ARIA 角色需配合键盘交互完整实现（Home/End/ArrowKeys/Enter/Space），普通跳转链接无需也不该用
  • 如果菜单支持折叠/展开，用 aria-expanded="true/false" 控制按钮，且必须同步更新 aria-controls 指向对应子菜单容器 ID

  data-module 比 id 更适合作为菜单 JS 锚点

  用 id="main-menu" 绑定 JS，看似方便，但一旦菜单组件被 Vue/React 多次渲染（比如商品页+首页都用同一组件），id 就重复了。document.getElementById('main-menu') 永远只返回第一个，后续实例的交互全部失效。

  而 data-module="main-nav" 是无状态、可复用的标识，配合 data-version="2.1" 还能做 CI 校验——构建时检查 HTML 片段是否匹配当前文档要求的版本。

  • 根容器统一加 data-module="main-nav"，子菜单加 data-module="dropdown-submenu"，避免模糊命名如 data-id="menu"
  • JS 初始化时用 document.querySelectorAll('[data-module="main-nav"]')，天然支持多实例
  • 禁止用 class 做 JS 查询主入口——类名会因样式迭代被重命名、拆分或废弃；data-module 只用于模块边界，与样式解耦
  真正难的不是写出能跑的多级菜单，而是让三个月后的你或新同事，能在 5 秒内看懂 DOM 结构里哪块是主菜单、哪块是子项、当前激活状态怎么表达、JS 绑定在哪——语义标签、data- 属性、ARIA 状态，三者缺一不可。