# HarmonyOS PromptAction 弹窗不显示怎么办：UIContext、页面销毁和回调兜底怎么拆
弹窗问题很容易被写成“接口没生效”，但我实际排查时更常见的是上下文已经不对了：按钮点击时页面还在，异步请求回来时页面可能已经返回；或者弹窗代码被放到工具类里，拿不到当前页面的 UIContext。这样写出来的问题不是每次都复现，越接近真实用户操作越容易露出来。
这篇只拆一个点：HarmonyOS 5.0.0 及以上版本里，promptAction 这类弹窗能力不要当成全局能力乱调。页面是否还活着、当前 context 是否正确、失败时有没有降级提示，这三个边界要先说清楚。
## 问题怎么出现
我用两个小场景复现这个问题。
| 场景 | 触发方式 | 表现 | 根因 |
| --- | --- | --- | --- |
| 案例一 | 点击按钮后立刻返回上一页 | 请求成功了，但弹窗没显示 | 回调晚到，页面已经销毁 |
| 案例二 | 工具类里直接调用弹窗 | 有时能弹，有时不弹 | 没有拿到当前页面的 UIContext |
这类问题麻烦的地方是：日志里通常能看到业务成功，但页面没有反馈。开发时看起来像“偶现”，其实是生命周期和 UI 调用边界没有拆开。
## 案例一：异步回调晚到
先看一个容易出问题的写法。按钮点击后发起异步任务，任务完成后直接弹窗。
```ts
@Entry
@Component
struct PromptBadCase {
@State message: string = '等待保存';
build() {
Column({ space: 16 }) {
Text(this.message)
Button('保存后提示')
.onClick(async () => {
await this.mockSave();
// 问题点：这里默认页面还在，但真实操作里用户可能已经返回。
promptAction.showToast({ message: '保存成功' });
this.message = '已保存';
})
}
.padding(24)
}
async mockSave(): Promise<void> {
return new Promise(resolve => setTimeout(resolve, 1200));
}
}
```
这个例子在普通点击时看不出问题，但只要用户点完按钮马上返回，回调晚到以后就可能出现 UI 反馈丢失。更稳的做法是给页面加一个轻量的 alive 标记，异步回来以后先判断页面还在不在。
```ts
@Entry
@Component
struct PromptSafeCase {
@State message: string = '等待保存';
private alive: boolean = true;
aboutToDisappear() {
this.alive = false;
}
build() {
Column({ space: 16 }) {
Text(this.message)
Button('保存后提示')
.onClick(async () => {
await this.mockSave();
if (!this.alive) {
return;
}
promptAction.showToast({ message: '保存成功' });
this.message = '已保存';
})
}
.padding(24)
}
async mockSave(): Promise<void> {
return new Promise(resolve => setTimeout(resolve, 1200));
}
}
```
这里不是为了多写一个变量，而是把“业务完成”和“页面还能不能显示反馈”分开。业务完成可以继续写缓存、写数据库、发事件；页面反馈只在页面仍然有效时做。
## 案例二：工具类里乱弹窗
第二个问题更隐蔽。很多项目会把 toast 封成一个全局工具：
```ts
export class ToastUtil {
static success(message: string) {
promptAction.showToast({ message });
}
}
```
看起来很省事，但一旦页面里有弹窗、半模态、NavDestination 或多窗口场景，工具类不知道当前 UI 层级。更稳的方式是让页面把“怎么提示”传进去，工具类只负责业务结果，不负责抢 UI 上下文。
```ts
type Notice = (message: string) => void;
class SaveRecipeUseCase {
async run(name: string, notice: Notice): Promise<void> {
if (!name.trim()) {
notice('名称不能为空');
return;
}
await this.mockWrite();
notice('保存成功');
}
private async mockWrite(): Promise<void> {
return new Promise(resolve => setTimeout(resolve, 500));
}
}
@Entry
@Component
struct PromptBoundaryCase {
private useCase = new SaveRecipeUseCase();
private alive: boolean = true;
aboutToDisappear() {
this.alive = false;
}
build() {
Column({ space: 16 }) {
Button('保存菜谱')
.onClick(() => {
this.useCase.run('红烧排骨', (message: string) => {
if (!this.alive) {
return;
}
promptAction.showToast({ message });
});
})
}
.padding(24)
}
}
```
这样拆以后，UseCase 不知道页面，也不需要知道 promptAction。页面负责把当前能不能提示、提示放在哪里说清楚。
## 两种处理方式怎么选
| 方案 | 适合场景 | 优点 | 风险 |
| --- | --- | --- | --- |
| 页面内直接判断 alive | 小页面、按钮回调少 | 改动小，能快速止血 | 页面多了以后容易重复 |
| 把 notice 回调传给用例 | 多页面复用、业务链路长 | UI 边界清楚，可测试 | 写法稍微多一层 |
| 全局 ToastUtil | 临时 Demo | 调用方便 | 上下文边界最差，排查困难 |
我的取舍是：只在很简单的页面里用第一种；只要弹窗来自 Repository、UseCase、异步任务或者跨页面回调，就用第二种。这样后面排查时能很快判断：业务有没有成功看 UseCase，页面有没有显示看 notice 回调。
## 可以封装成一个小保护器
如果项目里很多按钮都有同样的问题，可以把 alive 判断收口成一个页面内的小工具。
```ts
class PageNoticeGuard {
private active: boolean = true;
close() {
this.active = false;
}
toast(message: string) {
if (!this.active) {
return;
}
promptAction.showToast({ message });
}
}
```
页面销毁时调用 close，异步回调里只调用 guard.toast。这个封装不复杂，但它能防住一类很烦的偶现问题：业务回来了，页面已经不在了。
## 验证结果
我用两个动作验证：第一，点击按钮后不返回，页面能正常显示保存成功；第二，点击后立刻返回，异步回调不会再强行操作已经离开的页面。日志里仍然能看到业务完成，但 UI 层不会乱弹。
这个问题以后可以按三个问题自查：弹窗代码是不是在当前页面触发；异步回来时页面是不是还活着；工具类是不是偷偷承担了 UI 职责。只要这三件事拆清楚，promptAction 这类问题基本不会再靠猜。
