鸿蒙HarmonyOS菜单体验实战 —— bindMenu、bindContextMenu、Select 的正确打开方式
一、前言：菜单不是一个组件，而是一个体系
在开始写代码之前，必须先纠正一个最常见的误解：
鸿蒙的 Menu 不是一个"组件"，而是一个"弹出式菜单体系"。
很多开发者第一反应是去文档里搜Menu()，然后把它当普通组件放到页面树里：
// ❌ 错误心智：把 Menu 当普通组件 Column() { Text('我的页面') Menu() { // 这样写不会弹出 MenuItem({ content: '操作一' }) } }但官方文档写得很清楚：Menu()只能配合bindMenu/bindContextMenu使用，不支持作为普通组件单独使用。换句话说，Menu()是菜单的"内容容器"，真正让菜单弹出来的是通用属性bindMenu和bindContextMenu。
这背后的设计逻辑是：菜单本质上是一个弹出层（popup layer），它需要回答一连串问题：
由谁触发？（点击按钮、长按对象、右键、代码调用）
内容是什么？（简单命令列表、分组命令、带图标的选项）
弹在哪里？（ placement、offset、箭头、锚点）
是不是模态？（要不要蒙层、要不要阻止下层响应）
视觉质感？（圆角、模糊、材质、动效）
生命周期？（出现、消失、绑定组件销毁时怎么办）
这些问题分别由不同的 API 负责，所以官方文档才会把 Menu 拆成好几篇。理解了这一点，后面的内容就顺理成章了。
二、文档地图：官方文档为什么这么分散？
如果你打开鸿蒙官方文档搜 "Menu"，会发现相关文档散落在至少五个地方。E007 实验把它们的阅读顺序总结成下面这张地图：
Menu 文档地图（按阅读顺序） ├── 1. Guide：菜单控制（Menu） │ 先读，建立"场景 + 实践入口"的心智模型 │ 解释默认菜单、自定义菜单、右键/长按、振动、避让、锚点 │ ├── 2. Universal Attribute：菜单控制 │ 第二读，且必须长期作为权威 API 表 │ 真正的能力大多在这里：bindMenu、bindContextMenu、MenuOptions │ ├── 3. Basic Component：Menu │ 第三读，负责标准菜单"内容结构" │ 包含 Menu、MenuItem、MenuItemGroup、多级菜单、分割线 │ ├── 4. Select（Basic Component） │ 需要手机上的排序/筛选/模式选择时读 │ 是比 Menu 更高层的选择型菜单 │ └── 5. Immersive Light Sense（沉浸光感） D 阶段重点读，解释官方材质质感 从 API 26 开始影响 Menu 的视觉最佳实践
对应的职责矩阵：
| 文档 | 类型 | 负责什么 | 什么时候读 |
|---|---|---|---|
| Menu Guide | Guide + Sample | 怎么创建、怎么触发、避让、锚点 | 立题和第一次实现前 |
| Universal Menu Attribute | Reference | bindMenu、bindContextMenu、所有 options | 每次实现前必查 |
| Basic Menu Component | Reference | Menu()容器、子组件、结构 | 设计标准菜单结构时 |
| Select Component | Reference | 单选下拉选择器 | 手机排序/筛选时 |
| Immersive Light Sense | Guide | 官方材质质感 | D 阶段验证视觉时 |
关键结论：Menu Framework 的主文档是Universal Menu Attribute，不是 Basic Menu Component。真正的能力（触发、定位、预览、动效、模态、材质、生命周期）都在通用属性那一篇里。
三、能力地图：菜单的八个维度
把官方文档的能力点重新组织一下，可以得到一张更清晰的能力地图。这张地图是后面所有代码实现的"目录"：
HarmonyOS Menu 能力地图 ├── Trigger（触发） │ ├── bindMenu 点击 / 状态控制 │ ├── bindContextMenu 长按 / 右键 / 状态控制 │ └── Select 内建下拉触发器 │ ├── Content（内容） │ ├── Array<MenuElement> 简单 icon + text + action │ ├── CustomBuilder Menu() + MenuItem + MenuItemGroup │ └── SelectOption value / icon / symbolIcon │ ├── Structure（结构） │ ├── Menu 固定菜单容器 │ ├── MenuItem 命令行（图标、文字、快捷键、子菜单） │ ├── MenuItemGroup 分组 + 分组标题 │ └── SubMenu 通过 MenuItem.builder 实现 │ ├── Placement（定位） │ ├── placement / offset │ ├── enableArrow / arrowOffset │ ├── anchorPosition │ └── 折叠屏 / 2in1 中轴避让 │ ├── Modality（模态） │ ├── 非模态 bindMenu │ ├── 非模态 bindContextMenu（无 preview） │ ├── 模态 bindContextMenu（带 preview） │ ├── mask / MenuMaskType │ └── modalMode │ ├── Visual（视觉） │ ├── radius / font / divider / outline │ ├── backgroundBlurStyle ← 当前 SDK 可用 │ ├── Select.menuBackgroundBlurStyle ← 当前 SDK 可用 │ └── systemMaterial ← API 26，当前 SDK 未暴露 │ ├── Motion（动效） │ ├── 默认进出场 │ ├── previewAnimationOptions │ └── 沉浸光感空间动效 │ ├── Feedback（反馈） │ └── hapticFeedbackMode（需 VIBRATE 权限 + 系统设置） │ └── Lifecycle（生命周期） ├── aboutToAppear / aboutToDisappear（旧） └── onWillAppear / onDidAppear / onWillDisappear / onDidDisappear
记住一句话：选触发器决定菜单类型，选 options 决定体验细节。
四、Surface 决策规则：先问"选值"还是"执行命令"
在动手之前，先回答一个决定性问题。这是整个 Menu Framework 最容易被忽视、却最能避免返工的判断：
你这次的交互，是"选择一个值"还是"执行一个命令"？ 选择一个值（排序、筛选、模式、范围、密度） → 手机优先用 Select → Select 内建 trigger + value + arrow + selected-state + option 列表 执行一组命令（重命名、复制、分享、删除、归档） → 用 bindMenu 对象上下文 / 长按 / 右键 / 预览 / 代码触发 → 用 bindContextMenu
对应的决策表：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 排序方式（最近/名称/更新） | Select | 单选持久值，Select 内建选中态 |
| 视图模式（列表/网格） | Select | 同上 |
| 标题栏"更多"按钮 | bindMenu | 命令集合，非选择 |
| 列表项长按菜单 | bindContextMenu | 对象上下文操作 |
| 删除、归档、分享 | bindMenu | 命令动作 |
| 带预览图的长按菜单 | bindContextMenu + preview | 模态预览体验 |
| 代码控制打开/关闭 | bindMenu(isShow, ...) | 状态控制版本 |
手机上凡是"选择一个值"，默认优先 Select——这是 ArkUILab 在 E007 里明确沉淀的 ADR-004 决策。Select 的体验通常优于手写Button + bindMenu模拟的下拉框。
五、bindMenu 实战：从最简到分组子菜单
5.1 C1：最简菜单 —— Array<MenuElement>
最简单的菜单只需要一个bindMenu和一个命令数组：
@Builder private SimpleMenuButton() { Button('Simple bindMenu') .type(ButtonType.Capsule) .bindMenu([ &n