晚自习结束提醒是一个很适合新手练习的通知场景。点击“发布提醒”后，代码里的 Promise 可能很快返回；下拉通知中心，消息可能已经出现；但设备有没有真正发出自定义声音，还需要在目标设备上听一次。三件事往往发生在不同层，却常被一句“通知成功了”盖过去。

本文把一条提醒拆成三个问题：请求有没有被服务接受，通知中心有没有显示，声音有没有被人听见。工程使用固定的“19:00 晚自习结束”内容，不生成虚假的听觉结果。当前页面可以观察权限和 publish 状态；通知中心与声音仍需在目标设备人工核验。新手学会这三个停点后，面对任何提醒场景都能知道证据还缺哪一块。

一次提醒为什么会有三个结果

可以把通知想成一次接力。应用把请求交给系统，是第一棒；系统把消息放进通知中心，是第二棒；设备根据音量、勿扰和声音资源播放，是第三棒。前一棒完成，不代表后两棒自动完成。

图中每个菱形都是一个独立停点。publish 返回属于代码运行证据；通知中心截图属于系统视觉证据；声音是否实际播放属于人工听觉证据。页面上的绿色状态卡最多只能覆盖第一棒，不能替代后两棒。

先固定一条晚自习输入

新手练习不需要动态课程系统，只要固定标题、正文、通知 ID 和测试时间。工程可以使用“晚自习结束”作为标题，“请在 21:30 前离开教室并带走个人物品”作为正文，通知 ID 固定为一组测试值。固定输入的意义是让每次复测都能比较同一个消息，而不是在不同文案之间猜差异。

const request: notificationManager.NotificationRequest = {
  id: 92001,
  content: {
    contentType: notification.ContentType.NOTIFICATION_CONTENT_BASIC_TEXT,
    normal: {
      title: '晚自习结束',
      text: '请在 21:30 前离开教室并带走个人物品'
    }
  }
};

这段代码只说明请求对象的输入是什么。它没有调用系统，也没有证明通知已经出现。把标题和正文固定下来还有另一个好处：通知中心出现后，测试人员可以核对“这条消息是不是本次工程发布的”，不会把历史通知或其他应用的提醒误当成当前结果。

通知 ID 也不要随意每次递增。学习阶段使用固定 ID，方便重复发布同一条消息并观察覆盖或更新行为；如果业务需要多条不同提醒，再根据课程、日期和任务生成稳定 ID，并记录生成规则。ID 相同不等于声音必然播放，仍要单独查看系统结果。

第一停点：Promise 返回了什么

发布函数应把调用前校验、权限检查、Promise 成功和异常分别记录。不要在点击按钮时直接把状态写成“已送达”，而是等待 notificationManager.publish() 的 Promise 结果。

private async publishReminder(): Promise<void> {
  this.publishState = 'publishing';
  try {
    const enabled = await notificationManager.isNotificationEnabled();
    if (!enabled) {
      this.publishState = 'blocked';
      this.statusMessage = '系统通知未启用，未调用 publish';
      return;
    }
    await notificationManager.publish(this.buildRequest());
    this.publishState = 'published';
    this.statusMessage = 'publish Promise 已返回，请继续核验通知中心';
  } catch (error) {
    this.publishState = 'failed';
    this.statusMessage = `publish 失败：${this.formatError(error as Error)}`;
  }
}

这里的 published 只表示 Promise 正常返回。它可能意味着系统接受了请求，但不负责告诉应用“用户已经在通知中心看到了消息”，更不会返回扬声器是否发声。状态卡的说明文字要把这个边界写出来，防止新手看到绿色就停止复核。

如果权限查询返回 false，工程不应继续调用 publish，也不应把“未发布”改写成“静默成功”。页面可以提供开启通知入口，或让晚自习流程转为教室广播、班主任人工提醒等回退。回退证明的是业务还有出口，不证明 Notification 能力已工作。

第二停点：通知中心是否真的看见

Promise 返回后，测试人员要离开当前页面，打开系统通知中心，寻找固定标题和正文。这个动作必须在同一台设备、同一用户和相近时间完成。通知中心没有消息时，优先检查通知总开关、应用通知权限、通知渠道或系统清理策略；不要先去修改声音 URI。

通知中心截图只能证明视觉可见。它不能证明声音播放，因为设备可能处于静音、振动、勿扰、媒体音量为零或声音资源不可用状态。反过来，听到一声提示也不能证明正文正确显示，声音与文本是两个结果。

建议把通知中心验证写成一份三行记录：标题是否匹配、正文是否匹配、出现时间是否在发布后。若消息被折叠、延迟或覆盖，保留系统状态并记录通知 ID，不要用页面里的 published 字段替代。

第三停点：声音是否真的可听

自定义声音的最终验收必须在目标设备上完成。测试前固定系统音量、铃声模式、勿扰状态和输出设备；蓝牙耳机连接、扬声器占用、电话中断都会改变结果。工程能把声音字段传给请求，却不能从代码知道人耳是否听见。

若声音未听到，按顺序检查：系统通知开关、应用通知权限、通知渠道设置、设备铃声/通知音量、勿扰策略、声音资源是否存在以及 sound 字段是否匹配要求。每次只改一个条件，并保留上一轮结果。不要把“调大音量后听到了”写成“代码修复成功”，因为改变的是设备环境。

声音测试还要考虑重复发布。固定 ID 可能更新原通知而不是新增一条；系统是否重新播放声音要以目标设备观察为准。新手不应通过快速连续发布制造“肯定响了”的主观印象，应等待系统处理完成后再做下一轮。

用三栏状态表记录一次实验

把三个停点放在同一张表里，课堂讨论会清楚很多。左栏是应用状态，中栏是系统视觉，右栏是人工听觉；任何一栏空缺都不能被旁边的状态填补。

实验步骤	应用可记录	系统/人工可观察	结论边界
检查权限	enabled=true/false	系统设置页	只说明通知授权状态
调用发布	publishing/published/failed	Promise 返回或错误码	不说明通知已可见或发声
查看通知中心	标题、正文、ID	系统通知卡片	不说明声音播放
听觉核验	最近触发时间	人工听到/未听到	限定设备、音量和模式
关闭或回退	页面结束状态	人工广播、继续阅读等	回退不冒充原能力成功

这张表能纠正一个常见说法：“发布成功但没有声音，所以 publish 失败。”更准确的说法是：应用发布 Promise 已返回，通知中心可见性和声音结果需要分别核对。这样，开发者会去检查正确的层，而不是把所有问题都归因于一个 API。

三个适合课堂的单变量练习

练习一：只改变通知权限

先保持内容、ID 和设备声音设置不变，只关闭应用通知，再点击发布。预期是权限状态阻止发布；如果页面仍显示 published，说明状态链存在问题。恢复权限后重新发布，记录第二次状态，不用删除第一轮失败记录。

练习二：只改变系统可见性

保持权限和请求不变，分别在通知中心打开和关闭的条件下发布。观察 Promise 返回是否一致，再比较系统是否显示消息。这个练习说明应用收到的返回和系统界面展示不一定同步。

练习三：只改变听觉环境

保持请求和通知中心状态不变，分别使用响铃、振动和勿扰模式。记录人耳结果，不能只看 published。练习完成后恢复用户原来的声音设置，避免测试影响日常使用。

每个练习只改变一个变量，才知道差异来自权限、可见性还是声音环境。一次同时改三项虽然更容易“看到变化”，却无法形成可解释结论。

先读懂状态名称，再看颜色

新手页面经常用绿色、黄色和红色表示状态，但颜色只是辅助提示。真正需要读懂的是状态名称和它的来源。建议把晚自习提醒的状态分成五类：idle 表示还没有开始，publishing 表示请求正在进行，published 表示 Promise 返回成功，blocked 表示权限或前置条件阻止调用，failed 表示调用抛出错误。它们不应和“通知已看到”“声音已听到”共用一个枚举。

例如，页面显示 published 且通知中心卡片还没有出现时，应用状态没有错，它只完成了第一停点。此时可以继续等待系统，也可以记录系统策略导致的延迟，但不能把卡片状态硬改成“可见”。如果用户在通知中心看到了消息，页面可以新增一条视觉观察记录；如果随后在响铃模式下听到声音，再新增听觉记录。每一条记录都有自己的时间和来源。

状态分开还有助于处理重复发布。第二次点击时，如果第一条仍处于 publishing，按钮应暂时禁用，避免两次请求同时进入系统。第一次 Promise 返回后，才允许新一轮实验。若确实要测试重复发布，应为每轮生成尝试编号，并保留通知 ID、触发时间和结果，不要让后一次结果覆盖前一次异常。

把系统通知中心当成课堂里的第二个观察者

页面是应用自己的观察者，通知中心是系统观察者。两者看到的字段不完全相同：页面知道自己传了什么、Promise 返回什么；系统知道消息是否进入通知列表、是否被折叠或清理。新手应该学会在两个观察者之间做对照，而不是只盯着应用页面。

一次对照可以这样进行：发布前记录标题、正文和通知 ID；发布后等待一个固定观察窗口；打开通知中心核对同样的标题与正文；最后返回页面保存发布状态。若通知中心出现的是旧正文，先检查是否为固定 ID 更新或历史消息；若完全没有消息，记录系统开关和权限，而不是重写页面文案。

对照时要注意时间。系统通知可能因为调度、锁屏、后台限制或用户当前操作而延迟显示。文章不应写“点击后立即出现”这种没有测量依据的句子。更准确的表达是“在记录的观察窗口内看到”或“当前窗口未观察到”。时间限定让结果可复查，也给真机测试留下调整空间。

声音证据为什么必须由人来完成

代码中的 sound 字段只是一个请求属性。它可能指向应用沙箱中的资源，也可能使用系统默认声音；字段被写入请求，不等于音频已经通过系统策略到达扬声器。Notification 服务还要经过渠道设置、用户授权、音量模式和设备输出等环节，这些信息并不会全部回到 publish Promise。

听觉测试时，最好由两个人配合：一人负责触发并记录时间，另一人负责在不看页面的情况下判断是否听到目标提示。这样能减少“看到页面变绿所以以为听到了”的暗示。若只有一人，也可以先遮住页面状态，再按固定条件触发，随后记录“听到、未听到或无法判断”。无法判断应保留为待补，不要勉强写成成功。

测试还要注意声音来源。系统默认通知声、自定义沙箱声音和页面内临时播放的提示音不是同一条链路。文章中如果为了提示用户而播放页面音效，必须在文案里注明“人工回退声音”，并把它放在 Notification 听觉结果之外。否则读者可能以为自定义 sound 已经被系统验证。

一份可复制的课堂实验记录

下面的记录格式足够小，适合新手手写或复制到测试台账中：

尝试：N-01
输入：晚自习结束 / 21:30 / ID 92001
权限：enabled
应用：published（Promise 返回时间 21:05:12）
通知中心：待观察
听觉：待观察
设备条件：API 24，响铃模式，通知音量 60%

完成第二停点后，只更新“通知中心”一行；完成第三停点后，再更新“听觉”一行。不要因为最后一行是“待观察”就删掉前两行，它们正是说明链路走到哪里的证据。若发布失败，记录原始错误码和前置条件；若权限阻止调用，应用一行写“未调用 publish”，而不是“发布失败”。

这份记录也适合复测。下一轮可以复制 N-01，只改一个变量，例如把系统模式从响铃改成勿扰，并把尝试编号改为 N-02。比较两张记录时，读者能直接看到差异来自设备环境，而不是消息内容或代码分支。

失败后不要急着重新安装

通知没有出现时，重新安装应用可能暂时改变权限，却不能告诉我们问题在哪一层。更适合新手的排错顺序是：先读页面状态，再读系统通知开关，然后看通知中心，最后检查声音环境。每一步都保存结果，直到找到第一个不满足条件的停点。

如果页面显示 blocked，先处理权限，不要检查声音；如果 publish 抛错，保存错误码和请求摘要，不要用手动通知掩盖；如果通知可见但无声，检查勿扰、渠道和音量，不要重新构造正文；如果声音可听但正文旧，检查固定 ID 更新策略和通知中心历史。按层排查比重复安装更节省时间，也更容易写进后续测试报告。

只有当包损坏、路由异常或资源缺失等事实明确指向安装产物时，才需要重装。重装前保留原日志和台账，重装后建立新的尝试编号。这样不会把一次偶然恢复误写成“问题已经根治”。

固定通知 ID 应该怎样观察

固定 ID 是练习用的锚点，不是“永远只会有一条提醒”的承诺。不同系统版本和通知策略下，重复发布可能更新现有卡片，也可能呈现出不同的可见行为。新手应记录每次发布前通知中心是否已有同一标题，再在发布后对照卡片时间和正文，而不是只数列表里有几张卡片。

如果看到旧卡片被更新，记录为“同一 ID 的系统表现待复核”；如果看到两张卡片，也不要急着判断重复发布失效，先核对是不是测试期间换过 ID、换过应用构建或遗留了历史通知。固定 ID 的教学价值，是让输入稳定，从而把注意力放在三层结果上，不是替所有业务定义消息去重策略。

在业务里，课程提醒可以使用“课程日期加时段”的稳定 ID，使同一场晚自习的重试能关联到同一条记录。生成规则要写进台账，不能由页面临时拼接后消失。无论采用固定还是业务 ID，通知中心和声音结果都仍要各自采集证据。

实验结束后恢复设备条件

声音练习会改变通知音量、勿扰和输出设备。结束后应恢复测试前的个人设置，断开临时蓝牙设备，并记录恢复是否完成。这不是与技术无关的礼节：如果忘记退出勿扰，下一位同学的“无声”结果可能只是前一轮留下的环境；如果音量仍被调高，也会让日常使用受到影响。

恢复动作本身不证明 Notification 成功，但它让下一轮实验有干净起点。课堂可以把“恢复设置”作为最后一个检查框，和权限、通知中心、听觉记录并列。测试完成后再截图或归档时，只保存必要状态，不要曝光个人通知内容和设备标识。

何时可以升级文章中的结果表述

只有满足不同证据时，文章才能使用对应表述：publish Promise 返回后可写“请求被服务接受”；通知中心核对到固定消息后可写“当前设备通知可见”；在记录音量、模式和输出设备后由人工听到声音，才可写“当前条件下声音可听”。三条表述都应带上设备与时间范围。

缺少其中任何一项时，继续使用“待观察”“未取得”或“仅完成请求层”。这种写法不会降低文章价值，反而让读者能带着清楚的任务去补测。对新手来说，知道何时停止结论与知道怎样写代码同样重要。

回退路径让晚自习提醒不中断

如果通知服务不可用，晚自习结束仍应有替代方案。页面可保留教师人工发布、教室广播、班级群文字通知或查看课程页的入口。回退记录包括触发时间、责任人、使用的渠道和是否完成确认；它证明的是“提醒任务仍可交付”，不等于系统通知已发布。

回退按钮不要与原始发布按钮使用同一个成功状态。一个状态表示 Notification 请求，另一个表示人工处置。两个动作都完成时，页面可以展示“系统通知待证、人工提醒已确认”，而不是合并成“提醒成功”。这种分开对新手很重要，因为它让业务结果和平台结果同时可见。

FAQ

publish Promise 成功返回，为什么还要打开通知中心？

Promise 只说明服务接受了请求。通知是否在系统界面出现，需要系统通知中心的视觉证据；应用页面状态不能替代它。

通知中心看到了消息，是否可以说声音已经播放？

不可以。声音受通知渠道、设备模式、音量、勿扰和输出设备影响，必须在目标设备上人工听觉确认。

为什么固定通知 ID 适合入门练习？

固定 ID 让多轮实验容易对照，能观察同一条提醒的更新行为。它不保证每次都会新增通知或重新播放声音，最终行为仍要以设备验证为准。

没有声音时，能否在页面上播放一段提示音补救？

可以作为明确标注的人工回退，但不能把页面播放写成 Notification 自定义声音成功。两者调用链和证据来源不同，应分开记录。

结语

晚自习结束提醒的价值，不在于按钮按下后马上变绿，而在于它教会我们把一次通知拆成可回答的层：请求被接受、消息在系统可见、声音被人听见。对新手而言，三层证据比一句“通知成功”更容易复现，也更不容易在排障时走错方向。

当前工程和文章只把请求链路与状态边界讲清楚；通知中心和目标设备听觉结果仍按环境附录补证。保持这个边界，下一次遇到“消息出现但没响”或“声音响了但卡片不见了”，就能直接定位到对应停点。

必要条件｜故障前置排查

前置故障	检查位置	处理动作
SDK/API缺失	DevEco Studio SDK Manager、build-profile.json5	安装 API 24 并重新同步工程
Kit未引入或版本不匹配	当前页面 import 和编译错误	按 API 24 文档修正对应 Kit/API
页面或模块未配置	main_pages.json、module.json5	登记页面并补齐 Stage/权限配置
权限被拒绝	系统应用权限、abilityAccessCtrl 返回值	重新授权；拒绝时保持未运行状态
系统能力不可用	Camera、MapKit、SpeechKit、VisionKit 或文件运行状态	切换支持设备或走页面声明的降级路径

排查图片固定覆盖 SDK 配置、设备授权和运行版本；复杂技术再增加权限、能力和回调状态图。01要能看到 API 24/构建工具，02要能看到真实授权状态，03要能看到设备版本和能力状态。

SDK/API 故障排查：

权限故障排查后：

MapKit文章在地图服务故障排查后补充 AppGallery Connect 检查：项目、包名、签名、MapKit 服务开通状态和应用服务凭据/授权配置必须一致；不要用含密钥的控制台截图。