标签语义上表示命令集合，但浏览器渲染同，无原生菜单功能，需手动实现aria、键盘导航与焦点管理；静态列表用，交互式菜单应显式添加role和js控制。
<menu></menu> 标签在现代 HTML 中已基本退化为 <ul></ul> 的语义替代，浏览器渲染行为完全一致，但语义、可访问性和实际支持度差异显著——别把它当“高级 <ul></ul>”用，更别指望它自动变成工具栏或上下文菜单。
menu 标签的语义目标与现实落差
HTML 规范中，<menu></menu> 本意是表示“一组可执行命令”，比如工具栏按钮、右键上下文菜单。它理论上应配合 contextmenu 属性或 <menuitem></menuitem>（已废弃）使用，但现实中：
-
<menuitem></menuitem>在所有主流浏览器中已被移除，无法使用 - 没有浏览器会把纯
<menu><li><button>Save</button></li></menu>渲染成原生操作系统级上下文菜单 -
type="toolbar"和type="context"属性虽仍被解析，但无任何默认样式或交互行为 - 屏幕阅读器对
<menu></menu>的支持远不如<nav></nav>或带role="menubar"的结构稳定
ul 和 menu 的 DOM 行为与样式表现完全相同
浏览器引擎（Blink、WebKit、Gecko）对 <menu></menu> 的默认样式规则几乎完全复制自 <ul></ul>：缩进、上下外边距、list-style-type: disc。这意味着：
- 你写
<menu><li>Home</li></menu>和<ul><li>Home</li></ul>，CSS 选择器menu li和ul li会命中完全相同的渲染盒 - 不加 CSS 时，两者在视觉上无法区分；加了
list-style: none后也一样干净 -
<menu></menu>不提供额外的键盘导航逻辑（如 ArrowKey 切换、Enter 激活），这些必须手动用 JS 实现
什么场景下该用 menu，什么场景必须用 ul
真实项目中，选择依据不是“哪个更新潮”，而是“哪个更准确传达意图且不破坏兼容性”：
- 用于声明式、静态内容列表（如侧边导航链接、文章标签云）→ 用
<ul></ul>，语义清晰、兼容性 100% - 用于可交互命令集合，且你愿意手写 ARIA（
role="menubar"/role="menu"）、键盘事件和焦点管理 → 可用<menu></menu>，但需明确它是“语义占位符”，不是功能开关 - 需要兼容 IE 或旧版 Safari（
<menu></menu>在 Safari 15.4 前不支持type="toolbar"）→ 放弃<menu></menu>，统一用<ul role="menubar"></ul> - 构建组件库或设计系统 → 推荐绕过
<menu></menu>，直接用<div role="menubar"> + 自定义属性，避免语义污染和预期偏差 <h3>容易被忽略的兼容性雷区</h3> <p>即使你坚持用 <code><menu></menu>，以下三点不处理就会出问题：-
<menu></menu>在 HTML 文档流中仍是块级元素，但部分旧 CSS 重置库（如 normalize.css v7 之前）未给它设margin，导致与<ul></ul>布局错位 - 若嵌套
<menu></menu>（子菜单），必须显式加role="menu"和aria-haspopup="true"，否则屏幕阅读器无法识别层级 - 服务端渲染（SSR）框架若未正确声明
<menu></menu>的 namespace（如 XHTML 模式），可能触发 XML 解析错误
真正关键的不是标签名，而是你是否控制了角色（
role）、状态（aria-expanded）、焦点流和键盘响应——<menu></menu>不帮你做其中任何一件。 -
