通知权限拿到了发布还是失败

“通知权限已经开了，为什么发布还是失败？”

这句话听上去像在问通知服务，实际很多时候是在问页面状态。第一次做这个流程时，我把文件准备、通知授权和发布结果塞进一个笼统的“成功/失败”。页面一旦失败，大家都盯着权限；页面一旦成功，大家就默认铃声已经能听到。两边都不准确。

后来我把状态拆开才看清：权限 granted 只表示系统通知开关允许；文件准备完成表示 sound 有了候选输入；publish returned 表示服务接受了本次请求。三个阶段有先后关系，但没有一个可以替另一个盖章。

一个总状态，为什么特别容易误导

如果页面只有isSuccess，它会面临一个尴尬的问题。文件写入失败时该是 false，权限拒绝时也是 false，publish 抛错时仍然是 false。用户看到 false，根本不知道下一步要重试复制文件、去系统打开通知，还是检查请求参数。

现有页面没有把这些压成一个布尔值。它保留了文件、权限、发布、错误、最近操作和触发时间：

@State soundState: NotificationSoundState = { sandboxPath: '尚未准备', permissionState: 'unknown', publishState: 'idle', errorMessage: '暂无错误' }; @State fileState: string = '等待准备 EL1 文件'; @State lastOperation: string = '尚未操作'; @State lastTriggerTime: string = '尚未触发';

这一组状态像一张很小的工单。它不只告诉我“失败了”，还告诉我失败发生在哪个阶段、页面最后做了什么、这件事是什么时候发生的。对于会穿过文件系统、权限服务和通知服务的流程来说，这种分开记录比一个漂亮的成功图标实用得多。

我第一次查错，是因为把授权当成终点

当requestNotificationPermission()返回 granted 后，我以为最难的一段已经过去，便直接去看声音。可是发布函数还有一段明确的前置校验：

if (this.soundState.sandboxPath === '尚未准备' || !this.isValidSound(this.soundValue)) { this.updatePublish('failed', '发布前校验失败：请先成功准备 EL1 文件和 uri:: sound。'); this.markOperation('发布前校验失败'); return; }

也就是说，权限已经给了，发布仍然可以因为文件没准备好而被正确地拦下。这个 failed 不是通知服务拒绝，也不是权限突然失效；它只是页面不允许一个不完整的请求继续往下走。

以前我看见 failed 会立刻打开系统设置，后来才学会先读错误文本。它会告诉我“发布前校验失败”“通知权限未授予”还是“publish 失败”。同样是红色状态，走回去的路完全不一样。

串行流程为什么比并排点按钮更适合排错

页面提供了单独按钮，也提供runTrackedFlow()。后者把准备文件、核对权限、发布固定成顺序执行，中间任何一步不满足就停止。

private async runTrackedFlow(): Promise<void> { this.autoRunState = '串行流程运行中'; await this.prepareSandboxSound(); if (this.soundState.publishState === 'failed') { this.autoRunState = '串行流程停止：文件准备失败'; return; } await this.requestNotificationPermission(); if (this.soundState.permissionState !== 'granted') { this.autoRunState = '串行流程停止：通知未授权'; return; } await this.publishNotification(); }

我喜欢这个写法，是因为它不让失败后的页面继续假装“正在努力”。文件失败就停在文件失败，权限拒绝就停在权限拒绝。每个 return 都是一个清楚的分界线：在这之前已完成什么，在这之后没有发生什么。

如果把三个按钮随意并排点，排查记录很容易交错。你可能在文件还没写完时就触发发布，也可能在系统授权弹窗没处理完时再次发请求。最终状态看起来像随机的，实际只是操作顺序不受控。串行流程不保证所有系统问题消失，但至少把页面自己的顺序固定了。

状态拆分后的调用过程

这里的lastOperation和lastTriggerTime也不能省。一个状态值如果脱离时间，很难判断它是刚才这次操作留下的，还是页面自动流程第一次运行时的旧结果。尤其页面aboutToAppear()会调度一次自动验证，手动再次点击时更需要知道眼前看到的是哪一轮。

我会这样测试这页

测试不是只看最终published。我会人为观察每个停止点：文件准备失败、通知未授权、发布前校验失败、publish 返回。每个分支都有不同的页面文字，不能混成一张“失败截图”。

最后两步不是摆设。published表示 Promise 成功返回，不能替代系统通知栏是否显示，更不能替代人在设备上是否听到预期铃声。把这两层分开，遇到“通知有了但没声音”时就不会回头怀疑文件写入；遇到“声音设置没问题但通知被系统静默”时，也不会拿 URI 格式背锅。

失败后的复测也要回到起点

我不会在失败页面上只点一次发布再判断修好了。先记录fileState、permissionState、publishState、lastOperation和errorMessage，然后从准备文件重新走。若文件阶段已经失败，后面的授权和发布都不应被当作本轮结果；若权限状态不是 granted，则 publish 分支会在调用服务前停止。只有三个前置字段都符合预期，published才能说明这次notificationManager.publish的 Promise 已返回。

页面有固定通知 ID，也会在进入时调度一次自动流程，因此时间字段特别重要。人工点按钮前先看最近操作，能避免把页面首次进入时留下的状态当成刚才的结果。手动再跑一轮后，我会比较最近操作是否依次变成文件准备、授权核对、publish 返回或某个明确的停止原因；这种比较针对的是页面流程是否按顺序更新，不能借此替代系统通知是否可见或声音是否播放的确认。

这次问题让我留下的习惯

我把每一次 failed 都先翻译成人话

publishState=failed本身没有足够信息。它可能表示文件准备阶段已经失败，也可能表示发布前校验拒绝了输入，还可能表示通知未启用，或者服务调用抛出了错误。页面把具体原因放进errorMessage，把最近一步放进lastOperation，因此我会先读这两个字段，再决定下一步。错误写着准备文件失败时，不再申请权限；错误写着通知未授予时，不把 URI 拿出来反复转换；错误来自 publish 时，才保留该错误并检查请求条件。

这里有一个很容易忽略的后果：文件准备失败会同时让发布状态失败，但它不表示 publish 被调用过。源码在真正调用通知服务之前已经有输入门禁，沙箱路径还是尚未准备、或者 sound 格式不合规，就直接 return。写复盘时若把这种 failed 描述成“通知服务发布失败”，会把责任放到根本没有执行的调用上。相反，published只能对应 Promise 成功返回，表示请求被服务接受；它也不替代通知栏和人工听觉的确认。

权限状态也不是一次写死的标签。每次发布前代码都会再次调用isNotificationEnabled()，再把结果写回 permissionState。这个复核动作很重要，因为用户可能在两次操作之间修改系统开关，页面上旧的 granted 不能自动代表现在。回归时我会先观察发布前刷新后的权限字段，再看 publish 分支，而不是把先前授权弹窗的结果当成永久事实。这样状态来自本轮查询，问题单里的时间也更可靠。

自动流程和手动按钮并存时，顺序尤其要留意。页面进入后会延迟启动一次串行验证，随后用户还可以手动准备、授权、发布。如果只截取最终状态，很难知道那是自动运行留下的，还是刚才手动点出的。lastTriggerTime和lastOperation用来解决这个问题。我会在手动操作前记下旧值，操作后确认时间和操作名称已经变动，再解释对应的状态；不变就说明本轮动作没有走到预期位置，需要先检查触发而不是分析结果。

用停止点把回归分成几段

第一段只准备文件，要求 fileState 完成且 sound 满足格式；第二段只核对系统通知开关，记录 granted 或 denied；第三段才调用 publish 并看 Promise 结果。每一段结束都保存页面字段。某段失败后停止，不让下一段制造新的状态覆盖旧错误。下一次重试则从第一段重新开始，尤其是文件或 URI 失败后，不直接点发布。这个顺序不能保证外部系统一定展示通知，却能保证页面没有跳过自己的前置条件。

最后我会用两份独立记录收尾。一份是页面运行记录，内容是文件、授权、请求和异常；另一份是设备观察，内容是通知是否可见、何时观察、声音是否由人工确认。两份记录可以互相指向，但不能彼此代替。只有这样，遇到“请求返回却没有听到声音”时，才不会把不属于页面可证明范围的结果，误写成发布流程已经失败或成功。

为什么固定 ID 也要谨慎解释

固定通知 ID 有利于重复测试时识别同一类请求，却不能单独证明用户看到了哪一条通知。页面只是把 ID 放进请求，不读取系统界面的展示结果。测试记录里我会把它当作关联键：同一轮文件准备、权限核对和 publish 请求使用同一个 ID；系统界面若要观察，也另记观察时间。这样 ID 帮助对齐操作，不会被误用成系统可见或声音已播放的凭据。

我也会排除“权限已经 granted，所以错误一定在通知服务”的猜测。发布函数在服务调用前先检查 sound 输入，之后再即时查询通知开关，任何一层不满足都会提前结束。因而一张 granted 截图，只能回答某次查询的权限结果，不能证明当前请求已形成，更不能证明 publish 已经执行。真正判断服务调用有没有发生，要看最后操作是否写成发布固定 ID 通知，以及随后是 Promise 成功返回还是捕获到异常。

错误文本最好和本轮时间一起保存。没有时间的failed，可能来自页面刚进入时的自动运行，也可能来自用户后来的手动点击；没有操作名称的 published，也可能让人误以为是刚才那次按钮产生的。页面已经给出这两个字段，我会在每一段测试结束后记录它们，并在下一段开始前确认没有旧状态残留。这个动作看似繁琐，实际能避免最常见的误判：把上一轮文件失败，误读成这一轮授权后的发布失败。

如果需要测试拒绝和恢复，我会先把系统通知切到未启用，运行到明确的停止状态；再恢复开关，从准备文件重新开始，观察 permissionState 是否重新查询为 granted。恢复后也不跳过文件准备，因为页面运行的每一轮都应有自己的有效 sound 输入。这样测试覆盖的是状态分支和顺序，而不是依赖某次页面残留恰好让发布继续。到最后，系统通知是否展示、声音是否能被人工确认仍放在独立观察项中，不能由状态机自动写成结论。

这套记录方式还有一个好处：把页面能够控制的部分和设备外部的部分拆开。前者是准备、检查、请求和错误呈现；后者是系统展示和听觉感受。前者可以在页面字段中复查，后者需要现场观察。两类事实并列，而不是互相替代，才能在出现差异时知道应该回看哪一层。

我还会在复测结束后检查页面是否留下可解释的终态。文件成功、权限 granted、publish returned 时，错误应保持暂无错误，最近操作应对应本轮 publish；若中途停止，自动流程应写明停在文件还是授权，而不是继续显示模糊的运行中。这样测试不是只找一个绿色结果，也确认失败不会被后续按钮或旧状态覆盖。它让下一次排查从真实停止点重新开始，而不是从一个已经失去时间语境的总状态开始。

向团队同步时，我会把“授权状态正常”和“请求已返回”分成两句话。前一句来自系统开关查询，后一句来自 publish 的 Promise；两句话可以同时成立，也可以只成立其中一句。再把系统可见和听觉观察放到后面独立注明，就不会因为一句笼统的成功或失败，让文件、权限、服务和设备体验互相背锅。

每次记录都应标出这是自动流程还是手动流程。来源明确后，状态变化才有可追溯的操作语境，也便于发现重复触发带来的干扰。

回归时我会先让自动流程结束，再手动重新执行一轮，并分别记录两轮的最后操作与时间。若手动流程在文件、授权或发布任一点停止，就以那一轮的错误文本为准，不借用自动流程留下的状态。两轮都显示请求返回，也只能说明两次调用都有返回；系统界面和人工听觉仍要按各自时间单独观察，不能合并成一个成功判断。

• 文件准备、通知授权、发布结果必须分别显示。
• 每次状态变化都要带最近操作和时间，避免把旧结果当成新结果。
• published只能写成“发布请求已被接受”，不能写成“用户已经听到铃声”。

以前我希望通知页面只给人一个简单答案：成功或失败。现在更愿意让它给出一张短路线图。用户走到哪里，就看到哪里；没有走到的步骤，也不要替他涂成绿色。这样页面看上去不那么轻巧，出了问题却能很快找到该往回走的那一步。

本文依据现有文件准备、授权核对与 publish 状态路径撰写。系统通知可见性和自定义声音的实际播放，仍需目标设备上的系统界面与人工听觉单独确认。