文章目录前言这个案例为什么适合当第一课完整代码AlertDialog.show() 就是整件事的入口title 和 message 该怎么分工confirm 不只是按钮文案cancel 为什么也要认真写什么时候适合用 AlertDialog什么情况就不该再硬用它这个案例最值得记住的点容易踩的坑写在最后前言弹窗这种东西平时不起眼但几乎每个应用都会写。提示用户、请求确认、提醒风险、说明结果很多关键交互都要靠它来兜底。如果你刚接触 HarmonyOS7 的弹窗体系最适合先学的不是复杂自定义而是AlertDialog。因为它就是系统级的标准确认弹窗配置少、语义清楚、适合快速落地。这一篇就讲最基础的一种标题、消息、确认按钮、取消行为都齐全的AlertDialog。这个案例为什么适合当第一课它只做了一件事点一个按钮弹出一个基础提示框。但别小看这件事。标准弹窗的第一原则从来不是花而是清楚。用户必须一眼看明白这是什么提示、我能做什么、关闭后会发生什么。这个案例把最小结构收得很完整特别适合作为弹窗系统的起点。完整代码import{DEMO_CARD_COLOR,DEMO_THEME_COLOR}from./typesEntryComponentstruct AlertDialogStarter{StateisShow:booleantruebuild(){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和底部操作菜单思路会更清晰。