前言

弹窗这种东西，平时不起眼，但几乎每个应用都会写。提示用户、请求确认、提醒风险、说明结果，很多关键交互都要靠它来兜底。

如果你刚接触 HarmonyOS7 的弹窗体系，最适合先学的不是复杂自定义，而是AlertDialog。因为它就是系统级的标准确认弹窗，配置少、语义清楚、适合快速落地。

这一篇就讲最基础的一种：标题、消息、确认按钮、取消行为都齐全的AlertDialog。

这个案例为什么适合当第一课

它只做了一件事：点一个按钮，弹出一个基础提示框。

但别小看这件事。标准弹窗的第一原则从来不是花，而是清楚。用户必须一眼看明白这是什么提示、我能做什么、关闭后会发生什么。

这个案例把最小结构收得很完整，特别适合作为弹窗系统的起点。

完整代码

import{DEMO_CARD_COLOR,DEMO_THEME_COLOR}from'./types'@Entry@Componentstruct AlertDialogStarter{@StateisShow:boolean=truebuild(){Column(){if(this.isShow){Column(){Button('显示基础 AlertDialog').width('100%').height(48).backgroundColor(DEMO_THEME_COLOR).borderRadius(12).fontColor('#FFFFFF').fontSize(16).onClick(()=>{AlertDialog.show({title:'提示',message:'这是一个基础的 AlertDialog 弹窗，用于向用户展示重要信息或请求确认。',confirm:{value:'确定',action:()=>{console.info('用户点击了确定')}},cancel:()=>{console.info('用户取消了弹窗')}})})}.width('100%').padding(24).backgroundColor(DEMO_CARD_COLOR).borderRadius(12)}Text('AlertDialogStarter - 基础弹窗').fontSize(12).fontColor('#999999').margin({top:12})}.width('100%').height('100%').backgroundColor('#F5F6FA').padding(16)}}

AlertDialog.show()就是整件事的入口

核心代码非常集中：

AlertDialog.show({title:'提示',message:'这是一个基础的 AlertDialog 弹窗...',confirm:{...},cancel:()=>{...}})

你可以把AlertDialog.show()理解成一次“立刻展示标准对话框”的调用。它不需要你额外维护一个弹窗组件实例，也不需要自己管理显示状态，非常适合轻提示和轻确认场景。

title和message该怎么分工

案例里这两个字段都用了：

title:'提示'message:'这是一个基础的 AlertDialog 弹窗，用于向用户展示重要信息或请求确认。'

这两个字段不要混着写。

title负责一句话告诉用户“当前是什么类型的提示”，message负责补充更完整的说明。如果两者都写得很长，用户阅读压力会明显上升。

一个实用原则是：标题短、正文清楚、尽量不绕。

confirm不只是按钮文案

很多人第一次用AlertDialog，只盯着按钮上的字。其实confirm更重要的是动作承接：

confirm:{value:'确定',action:()=>{console.info('用户点击了确定')}}

这里的value是按钮文案，action是用户确认后的处理逻辑。现实业务里，这里可能接的是提交操作、状态切换、删除执行或者页面跳转。

所以弹窗本身只是门，action才是门后面的事。

cancel为什么也要认真写

案例里取消行为也单独写了：

cancel:()=>{console.info('用户取消了弹窗')}

这是个好习惯。

很多人觉得取消就是“啥也不做”。但在真实交互里，取消本身也是一种明确选择。有时你要恢复页面状态，有时你要记录用户放弃操作，有时你至少要保证没有误执行后续流程。

尤其做重要确认时，取消路径绝不能含糊。

什么时候适合用AlertDialog

这类标准弹窗特别适合几种场景：

• 一次性信息提醒
• 简单确认
• 低复杂度风险提示
• 不需要自定义布局的说明弹窗

如果你只是想告诉用户“操作完成”“请确认”“当前网络异常”，AlertDialog通常就够了。

什么情况就不该再硬用它

当你需要表单输入、选项列表、复杂样式、插图内容、多个操作按钮，或者你想完全控制弹窗布局时，AlertDialog就不够用了。这时候应该转向CustomDialog。

也就是说，它擅长的是标准化确认，而不是承载复杂内容。

这个案例最值得记住的点

不是 API 有多简单，而是它传达了一种很重要的交互习惯：系统标准弹窗就该负责“明确、克制、快速确认”。

你如果把所有轻提示都优先用标准弹窗解决，页面会稳定很多，也更符合用户预期。

容易踩的坑

第一个坑，是正文过长，用户点开以后得读半天还抓不到重点。

第二个坑，是确认按钮动作写得太重，但文案又太轻，导致用户没有真正意识到后果。

第三个坑，是取消路径没处理好，页面状态留下一半。

写在最后

AlertDialog的价值，不在于它多高级，而在于它足够标准。很多弹窗需求其实根本不需要自定义，直接用系统级确认框，反而更省心也更稳。

先把这类基础弹窗用顺，再去碰确认/取消流、CustomDialog和底部操作菜单，思路会更清晰。