首发于华为开发者论坛：https://developer.huawei.com/consumer/cn/blog/topic/03226498246684304

提醒、通知、日历事件这类功能，结果是系统侧异步兑现的，所以 API 的返回值说的是「请求已受理」，不是「事情已发生」。我把这两句话当成了一句话，同一个坑连踩了三次。

三次都没有报错，没有异常，没有一行红色日志。能拿出来的"事故现场"就一句话：返回值是正常的。

第一次：用户点了「禁止」，代码走的是成功分支

1.0.0 的授权流程用的是requestEnableNotification。我当时的理解是：用户同意它就 resolve，用户拒绝它就 reject。实际上用户点「禁止」它照样 resolve，应用把这台设备当成已授权，继续往下走。我以为是设备通知设置的问题，让用户去把通知打开。

开了，还是不响。

第二次：通知开关关着，publishReminder 返回了一个体面的 id

还是 1.0.0。通知开关关闭时调publishReminder，不抛异常，返回一个正常的提醒 id——然后那条通知永远不会弹出来。我这回怀疑是提醒时间算错了，去查时间计算。时间是对的。

第三次：我加了日志，日志说成功

到 1.2.1，提醒改走日历事件。这回我学"聪明"了，加日志打addEvent的返回值。返回了 id。界面上明明白白显示着「提醒 18:06」。但在一台从没打开过日历应用的设备上——审核那边的机器就是这样——日历应用未初始化，事件写进了库里就躺在那儿，提醒不会响。

代码、日志、UI 三方合谋，每一方都在说"它在工作"，包括写它的人在内，所有人都信了。

三次之后我才看明白差在哪一步

三次排查方向各不相同：第一次怪设备设置，第二次怪时间计算，第三次去验写入结果。但它们共用同一个错误前提——把「调用方的返回值」当成了验收判据。这个前提在我自己的开发机上查不出来：开发机的日历初始化过、通知授权过、权益齐备，"请求已受理"和"事情已发生"在这台机器上几乎总是同时成立。同一份代码，在这里是对的，在那里是错的。

这也是它能连踩三次的原因：成功路径在开发机上是真的成功，错误的前提在开发环境里永远不会暴露。

修的时候我给判据排了个序

宣称成功之前，判据分三级：权威回读 ＞ API 返回值 ＞ 无异常。能回读就回读——事情做没做成，去系统侧把结果读回来。有些外部状态压根没有查询接口，回读不可达，那时代码层正确的动作是向用户如实降级表述：记一个lastViaFallback标记，界面上说清楚这次走的是备用路径。不能验证的成功不许宣称。

比防御代码更管用的是架构层的动作：给这类功能配主路径之外的降级路径，且几条路的失效前提要正交——权益状态、日历状态、进程存活，各失效各的，互不重叠才算冗余；三条路都依赖同一个前提，那就还是一条路。前两次事故我都加过防御代码，第三次照样以新形态出现；真正终结它的是把主路径换成了零外部依赖的那条。

还有一条不许再犯：发布失败不许静默。旧代码里publish失败返回 -1，被 UI 吞掉，外观就是"设了提醒没反应"。失败必须明示。

怎么算修好：坐在那儿等它响

效果侧的验收就一种做法：设一个提醒，退到后台，真的等它响。通知栏出现那条通知才算过。返回值不算，界面显示「提醒 18:06」不算，日志无异常也不算。

想在自己工程里复现，三分钟：在系统设置里拒绝该应用的通知；调requestEnableNotification，打印返回的是 resolve 还是 reject；再调publishReminder，打印返回值。你会看到两个"成功"，而通知不会来。

边界：别把这条读过头

它不是说 API 返回值都不可信——绝大多数同步 API 的返回值就是结果本身。判别式就一句：这个调用完成之后，事情是不是还要靠别人做？要靠系统侧接着兑现的（提醒、通知、推送、卡片刷新），返回值才仅仅是"已受理"。

另外，"功能过简"那类驳回和这条无关，那是产品维度的事，测试与判据都救不了。

这是《鸿蒙开发踩坑实录》第 14 篇。后来我发现自己在别的事上也在拿「调用成功」冒充「事情发生」。

本文由作者与 AI 协作整理，事实经作者核验。