企业官网建设流程全解析

一、前言：菜单不是一个组件，而是一个体系

在开始写代码之前，必须先纠正一个最常见的误解：

鸿蒙的 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 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——这是 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