鸿蒙为开发者提供了多种自定义弹框方案，但三者定位不同，简单来说：OpenCustomDialog是官方推荐的轻量级方案，适合动态创建和更新弹框；CustomDialog是早期的传统方案，写法简单但不够灵活；DialogHub则是一个强大的三方库，专门解决复杂场景下的弹框管理问题。
我把它们的核心区别整理成了下面这个表格，方便你对比。
核心区别对比表
| 特性维度 | OpenCustomDialog (推荐) | CustomDialog (传统) | DialogHub (三方库) |
|---|---|---|---|
| 核心定位 | 与UI解耦的全局弹框API，轻量灵活 | 基于@CustomDialog装饰器和CustomDialogController的组件化弹框 | 全局弹框管理中心，提供队列、栈管理等高级能力 |
| 实现机制 | 通过PromptAction和ComponentContent封装内容，与UI上下文解耦 | 依赖CustomDialogController，与UI组件（如@Entry）紧密绑定 | 作为独立的三方库，提供统一的弹框注册、显示、隐藏和堆叠管理 |
| 动态性 | 支持动态创建和更新内容（updateCustomDialog） | 不支持动态创建和刷新，控制器需预先定义 | 支持，通过管理机制可灵活调度和更新弹框 |
| 生命周期管理 | 需手动管理ComponentContent，及时dispose()释放资源 | 由CustomDialogController管理，相对被动 | 提供全局生命周期管理，包括队列和堆叠顺序控制 |
| 适用场景 | 轻量级、动态、需要内容更新的弹框（官方主推） | 简单、静态、不频繁变化的自定义弹框（较不推荐） | 复杂交互、多步骤引导、全局弹框管理、特殊交互需求（如手势透传） |
1. OpenCustomDialog：官方推荐的现代化弹框方案
它解决了CustomDialog的痛点，是更灵活的选择。
工作机制：通过
ComponentContent将弹框内容（@Builder函数）与UI页面解耦，通过PromptAction来控制其打开、关闭和更新。核心优势：
动态更新：弹框显示后，可通过
ComponentContent.update()动态刷新内容，这在CustomDialog中难以实现。真正的全局性：不依赖特定页面，可在应用的任何位置调用，非常适合封装成工具类。
关键用法：通过
ComponentContent封装@Builder，调用promptAction.openCustomDialog()显示，通过updateCustomDialog()更新，关闭后需调用dispose()回收资源。
2. CustomDialog：传统的组件化弹框方式
这是较早的弹框实现方式，当前官方不再推荐用于复杂场景。
工作机制：通过
@CustomDialog装饰器定义一个弹框组件，并在页面中使用CustomDialogController来控制它的显示与隐藏。主要局限：
CustomDialogController必须和页面组件绑定，无法动态创建或更新弹框内容，对于复杂、动态的场景显得有些笨重。适用场景：对于非常简单的、内容固定、无动态更新需求的弹框，它依然是一种可选方案。
3. DialogHub：解决复杂弹框管理的“专业选手”
它不是一个基础的API，而是一个专业的弹框管理框架，旨在解决应用内复杂的弹框交互问题。
主要能力：
全局统一管理：提供注册、显示、隐藏、队列和堆叠管理能力，轻松应对多步骤引导等场景。
复杂交互支持：解决焦点抢占、手势透传、遮罩动画自定义等棘手问题。
UI解耦与模板复用：支持将弹框与UI完全解耦，并可创建弹框模板供全局复用，提升开发效率。
适用场景：当应用需要统一管理大量弹框，或实现引导页、多步骤流程、需要特殊交互（如不打断用户操作的非模态弹框）时，DialogHub是理想选择。
如何选择？一张决策图帮你搞定
需要动态更新内容？全局调用？开发新功能？→选择 OpenCustomDialog。它几乎是现代鸿蒙开发的首选。
应用内弹框逻辑复杂（如新手引导）？需要特殊交互（如手势透传）？→考虑引入 DialogHub。它是一个强大的工具箱，能帮你解决不少麻烦。
维护一个非常简单的、静态的旧代码弹框？→可以继续使用 CustomDialog。但新代码建议优先考虑前两者。