网页显示已允许通知，为什么仍收不到：许可状态、服务工作线程与系统投递怎么分

浏览器地址栏显示“通知：允许”，用户却一直收不到提醒。这个现象不能只用“网站没发”或“系统坏了”解释。网页通知从许可到屏幕出现，至少要经过许可、订阅、应用服务器、推送服务、服务工作线程和操作系统呈现六层。

许可状态只回答网站能否尝试调用通知API。它不保存一条永远有效的送达承诺，也不证明网站已经建立推送订阅。把granted直接翻译成“以后每条都会收到”，会跳过后面所有环节。

许可允许调用，不负责投递

WHATWG Notifications标准规定，通知许可不是granted时，服务工作线程的显示步骤会被拒绝。这个规则说明许可是必要条件，却没有说它是充分条件。即使许可允许，代码仍可能没有执行，订阅可能失效，系统也可能把通知放入安静区域。

许可还可能有三种状态：尚未决定、允许或拒绝。网站自己的开关与浏览器权限不是同一个字段；网站账户中打开“接收提醒”，浏览器仍可能拒绝。反过来，浏览器允许而网站账户关闭，也不会产生业务消息。

测试时先记录来源域名和浏览器显示的许可状态。不要只看操作系统总开关，因为浏览器内部还可能按网站保存权限。也不要连续弹出请求；浏览器可能限制缺少用户操作或被反复拒绝的请求方式。

本地能显示一条测试通知，证明许可与显示接口在当时可用，但不能证明远端消息链。这个差别是后面所有排查的起点。

推送订阅是独立对象

W3C Push API说明，网页应用通过服务工作线程注册建立推送订阅。订阅包含推送端点和发送所需的密钥信息，并绑定具体来源与服务工作线程注册。许可保存在浏览器权限层，订阅则是推送服务中的可寻址对象。

清除网站数据、移除服务工作线程或更换浏览器配置后，许可界面有时仍需单独观察，但旧订阅端点可能已不再对应当前环境。应用服务器若继续向数据库中的旧端点发送，用户不会因为权限仍显示允许就自动收到。

W3C还规定，服务工作线程注册被移除时相关订阅需要停用，推送服务也可能更早终止订阅。排查时应读取当前订阅，而不是只确认服务器数据库里“曾经有一条”。

为了保护安全，不要在公开截图中展示完整订阅端点或加密密钥。记录端点的短指纹、创建时间、浏览器配置和是否与服务器记录一致即可。端点是能力URL，泄露本身会扩大风险。

应用服务器成功不等于屏幕出现

应用服务器把消息交给推送服务时，会得到HTTP层响应。响应能说明推送服务是否接受请求或端点是否明显失效，却不是用户已经看见的回执。消息还要等待用户代理连接、触发后台事件并执行显示代码。

RFC 8030允许推送服务终止订阅。应用服务器向过期订阅发送时应得到404，因此服务器日志中的状态码是重要证据。若发送程序吞掉错误或重试逻辑只记“任务完成”，运营人员可能把失败误写成发送成功。

协议还定义可选的推送消息回执，但回执所在边界仍不是用户视觉确认。推送服务确认交付到用户代理，与操作系统展示横幅、声音或通知中心记录，是不同阶段。

服务器记录至少要包含业务消息标识、订阅指纹、提交时间、响应状态、实际TTL和错误类别。不要保存完整内容中的敏感资料；诊断投递不需要复制用户隐私。

TTL决定离线后还等不等

RFC 8030要求每条推送消息带TTL，表示推送服务可保留消息的期限。期限届满后不得继续尝试投递。终端关机、离线或浏览器长期未连接时，短TTL消息可能在恢复网络前已经失效。

TTL为零表示只尝试立即投递。用户代理当时不可用，消息会过期且不再送达。这样的设置适合已经失去时效就不应出现的状态，却不适合用户期待离线后补看的提醒。

推送服务也可返回比应用服务器请求更短的实际TTL。发送端还需考虑消息从应用服务器到推送服务、再到用户代理的延迟。日志只保存原请求TTL而不保存服务响应，会遗漏真实保留期限。

比较测试时固定消息内容与终端，只改变TTL。一条使用较长TTL，一条使用零TTL，然后让终端短暂离线。恢复后只有前者出现，并不说明权限变化，而与消息保留策略一致。

服务工作线程负责接住事件

推送消息到达用户代理后，浏览器会在需要时启动关联的服务工作线程并派发push事件。脚本必须在事件处理期间读取资料、完成必要工作并调用显示接口。事件到达与通知显示不是同一动作。

服务工作线程可能未安装、正在等待新版本、被清除或注册在不同scope。MDN对showNotification的说明也列出线程需处于可用状态，安全上下文与许可仍需满足。只检查页面脚本是否加载，无法代表后台注册状态。

更新工作线程时，新旧版本还可能短暂并存。页面由旧控制器管理，服务器却预期新代码处理负载，会造成只在部分标签页或设备发生的差异。记录当前脚本URL、注册scope、active状态和版本标识，才能知道哪段代码实际接收事件。

push事件日志应区分“事件从未出现”“事件出现但解析失败”“解析成功但未调用显示”“调用显示返回拒绝”。四种结果指向不同层，不应合并成一个通知失败。

显示调用之后还有平台层

WHATWG把通知定义为发生事件的抽象表示，并要求与平台通知系统整合。浏览器成功创建通知后，操作系统可能根据免打扰、专注模式、应用通知类别、声音设置和通知摘要改变呈现。

没有横幅不等于没有通知。有些系统会把它放入通知中心但不响铃；有些会在专注模式结束后汇总。锁屏隐私设置还可能隐藏正文，仅显示应用名称。排查应分别看横幅、声音、角标和通知中心记录。

系统设置也可能按浏览器应用，而不是按网站显示。浏览器里网站权限为允许，操作系统却关闭整个浏览器的通知，显示调用可到达浏览器层但用户看不到预期提醒。

多设备同步会让现象更复杂。同一账号的笔记本订阅有效、手机订阅过期，服务器可能只发送到其中一个端点。不能因为另一台设备收到，就假定当前设备的订阅也正常。

事件时间、发送时间和显示时间分开

Notifications标准允许通知携带时间戳，用来表示事件实际发生的时间；设备离线时，显示可能晚于事件。时间戳由应用提供，不是推送服务自动生成的完整投递证明。

一条通知至少有四个时间：业务事件发生、应用服务器提交、用户代理接收push事件、系统显示。再加上用户点击，就形成第五个时间。只保留通知屏幕截图，会把前面三段全部压缩。

时区也要固定。服务器用UTC、设备用本地时间，若日志没有时区，看起来可能出现显示早于发送。测试记录同时保留ISO时间与时区偏移，避免把格式差异当成时序错误。

通知晚到时先看事件时间和TTL。若事件本来已经过时，应用可决定不显示；这属于产品策略，不是投递故障。若应用仍显示旧消息，时间戳能帮助用户理解它发生在过去。

本地测试与远端测试回答不同问题

本地调用showNotification，验证许可、服务工作线程状态和平台显示路径。它绕过应用服务器、订阅端点、推送服务与TTL，因此通过本地测试不能宣称推送正常。

远端端到端测试需要服务器向当前订阅发送带标识的消息，并在浏览器记录push事件。若服务器响应成功但没有push事件，问题靠近订阅或推送服务；若push事件出现而没有显示，则靠近事件处理或平台层。

测试消息应使用非敏感文字和唯一标识，避免与真实通知混淆。一次只测试一个设备和一个浏览器配置，随后再比较第二台设备。多个端点同时发送会让日志难以对应。

一条测试成功只证明当时链路可用。电池策略、网络、后台限制和订阅轮换都会改变后续结果，因此需要在发生问题的同类条件下复测。

七栏排查表

第一栏是许可：来源域名、浏览器状态和操作系统总开关。第二栏是服务工作线程：脚本URL、scope、active版本。第三栏是订阅：是否存在、端点指纹、创建时间和服务器是否匹配。

第四栏是发送：消息标识、提交时间、响应状态和错误。第五栏是有效期：请求TTL、服务返回TTL与终端离线时段。第六栏是后台事件：push事件时间、解析结果和showNotification返回。第七栏是系统呈现：横幅、声音、通知中心和点击时间。

按许可、订阅、服务器响应、TTL、push事件、showNotification和系统通知中心七栏记录同一次测试。空白表示没有证据，不用“正常”两个字代替具体状态。

许可为granted但当前订阅为空，先重新建立订阅并同步服务器。服务器返回404，移除过期端点。push事件存在而显示调用失败，查看异常与工作线程状态。通知中心有记录但无横幅，则回到系统呈现设置。

不同浏览器与系统不能强行统一

Push API和Notifications API给出共同模型，具体权限界面、后台时机、通知样式和省电策略仍由浏览器与操作系统实现。桌面端通过的步骤，不能直接保证手机端相同。

浏览器可能选择不同推送服务，也可能因网络、防火墙、企业策略或电池影响连接。W3C明确允许用户代理在推送服务选择上考虑可用性、可靠性和电池。诊断报告应写浏览器和系统版本。

应用安装成PWA、普通标签页和浏览器关闭后的行为也可能不同。不要用“网页关闭”一个词描述，应注明标签页关闭、浏览器进程退出、系统强制停止或设备重启。

企业设备还可能有管理策略覆盖用户选择。个人权限界面显示允许时，组织层策略仍可能限制后台或通知。无法读取策略时就标记未知，不建议绕过管理保护。

结论：允许只通过第一道门

通知许可为granted只是调用显示步骤的前置条件，推送订阅和服务工作线程仍需分别有效。应用服务器向订阅端点发送消息，推送服务交给用户代理，服务工作线程处理事件并调用showNotification，平台最后呈现。

服务器收到响应不等于用户已经看见，通知中心没有记录也不能单独证明应用服务器从未发送。本地显示测试通过，只验证链路后半段；端到端测试必须把订阅、TTL和push事件一起纳入。

最有效的排查不是反复切换许可，而是保存同一次消息在七层的时间和结果。只要能说清失败停在哪一栏，就不必用一个“允许”开关解释整条投递链。

先把一次失败固定成可复现样本

通知问题常被不同时间、不同设备的零散截图拼成一个故事。更可靠的办法是先选择一台设备、一个浏览器配置和一个当前订阅，生成不含敏感信息的测试消息标识。发送端、服务工作线程和页面诊断面板都使用同一标识，后续记录才不会把两条消息混在一起。

测试前不要急着清除网站资料或重新授权。清除动作会改变订阅、工作线程和缓存，原来的失败现场随之消失。先保存许可状态、注册scope、active脚本URL、订阅端点短指纹、系统通知开关与当前时间，再执行一次远端发送。只有在证据保存后，重新订阅才是修复动作而不是掩盖现象。

如果问题只发生在后台，测试条件也要还原后台。分别记录标签页在前台、标签页关闭但浏览器仍运行、浏览器进程退出和系统强制停止四种状态。这些状态对用户都可能叫作“关掉网页”，对浏览器却是不同的运行条件。不能用前台成功的一次测试替代后台失败的现场。

用证据组合定位，而不是用单点猜原因

许可为granted、当前订阅存在、服务器返回接受，但浏览器完全没有push事件，说明显示层还没有机会执行。此时应比较发送的端点指纹是否与本机当前订阅一致、TTL是否覆盖离线时段，以及推送服务是否返回了实际有效期。反复切换系统免打扰不会修复订阅或传输层。

push事件已经出现，解析过程却抛出异常，则订阅与推送服务至少完成了这次事件的前半段。检查消息格式、解密结果和事件处理是否用waitUntil等待异步工作。这里的目标不是证明整条链正常，而是把故障边界缩小到事件处理代码；仍不能据此承诺下一条消息一定显示。

showNotification调用成功且通知中心有记录，却没有横幅或声音，证据指向平台呈现策略。此时查看专注模式、通知摘要、声音与锁屏类别更合理。若通知中心也没有记录，还要保留调用返回和异常日志，避免只凭肉眼把脚本失败与安静呈现混为一谈。

服务器返回404则应把该端点标为失效，并由客户端重新建立订阅后同步新端点。不要无限重试同一能力URL，也不要因为数据库中仍有记录就把它算作活跃设备。数据库字段代表服务器曾保存过对象，HTTP响应才是这次提交的重要边界证据。

许可变更后的恢复需要两边对账

用户曾拒绝通知再改为允许时，网站不应只更新界面文字。客户端需要确认服务工作线程已激活、读取现有订阅，必要时建立新订阅，再让应用服务器用端点指纹确认记录已更新。任何一步失败，都应显示具体状态，而不是把按钮统一写成“已开启”。

清除浏览数据后的情况类似。浏览器可能移除工作线程与订阅，服务器却仍保存旧端点。恢复流程应由客户端产生当前事实，服务器据此替换或停用旧记录；不能由服务器把旧订阅重新推给浏览器。订阅绑定来源和注册环境，复制数据库值不会重建本机后台能力。

多设备账号还要按端点逐条管理。用户在手机关闭通知，不应误删笔记本的有效订阅；某个端点返回404，也不表示账号的所有设备都失效。记录设备别名可以方便用户操作，但诊断和发送仍以订阅端点指纹为准。

设计日志时守住隐私边界

完整推送端点、加密密钥、通知正文和账号资料不该出现在公开工单。诊断只需要消息标识、端点短指纹、状态码、时间、TTL、浏览器版本和事件阶段。若正文内容会影响解析，可使用结构相同的测试负载重现，不必复制真实消息。

日志保留期也应与问题调查需要相称。长时间保存每次通知正文并不会让许可、订阅或TTL更容易判断，反而扩大资料暴露面。对操作人员而言，可关联的阶段时间与明确的失败类别，比收集更多用户内容更有价值。

最终报告应写明证据能证明什么，也写明不能证明什么。服务器接受证明请求进入推送服务边界，不证明用户看见；push事件证明用户代理收到事件，不证明系统展示横幅；通知中心记录证明平台保存了通知，不证明用户读过。把这些边界保留下来，才不会在下一次故障时又从权限开关重新猜起。

资料来源

• WHATWG：《Notifications API Standard》，发布或更新于 2026-03-15
• World Wide Web Consortium：《Push API》，发布或更新于 2025-12-01
• Internet Engineering Task Force：《RFC 8030: Generic Event Delivery Using HTTP Push》，发布或更新于 2016-12-01
• Mozilla：《ServiceWorkerRegistration: showNotification() method》，发布或更新于 2026-05-25