HTML通知能改善消息推送吗？对比与快速上手

先说结论：不能。HTML 通知（即 Notification API）本身对消息推送能力没有任何改善。它只做一件事——把已经到达浏览器的消息“弹出来”。至于消息能不能进入浏览器，它完全管不了。

为什么调用 new Notification() 后用户收不到“推送”

很多开发者在调试时会发现：页面一刷新，通知就消失；标签页一关闭，通知石沉大海；手机切换到后台，连接立刻断开。

根本原因在于，Notification API 是一个纯前端的同步渲染机制。它既不参与网络通信，也不维持任何连接：

• 必须由当前页面的 JavaScript 主动执行 new Notification() 才能显示；
• 页面未加载、JS 未运行、浏览器休眠或者标签页被挂起时，这行代码根本不会执行；
• 它不加密、不认证、不依赖任何推送协议，与服务端向设备主动发送消息完全是两码事。

因此，所谓的“收不到推送”，本质上是消息根本没有传送到浏览器内，跟通知是否弹出来无关。

Notification.permission === "granted" 但仍没通知？请检查这三件事

权限已授权，并不等于通知能稳定触发。以下几个容易被忽视的坑，需要逐一排查：

• Notification.requestPermission() 必须由用户手势触发，例如点击按钮。在页面 onload 或定时器中直接调用，浏览器会静默忽略；
• 必须运行在安全上下文中，即 https:// 或 http://localhost（需带端口）。部分 Chrome 版本中，http://127.0.0.1 也不被允许；
• iOS Safari 对 Notification API 的限制非常严格：只允许在前台页面触发，不支持 tag 去重，icon 渲染也经常失败。

想让通知“像推送一样可靠”，必须搭配 Service Worker + Push API

页面关闭后仍能稳定收到并弹出通知，真正合规的路径只有 Web Push 这一条链路：

• navigator.serviceWorker.register('/sw.js', { scope: '/' }) 必须注册成功，且 scope 要覆盖页面的路径；
• 必须等到 navigator.serviceWorker.ready 完成 resolve 之后，再调用 registration.pushManager.subscribe()，否则会直接报错 Registration is not ready；
• 服务端推送必须走 Web Push Protocol（例如 FCM v1 API），并且 payload 中需显式包含 webpush.notification 字段，否则只会触发 push 事件，而不会调用 showNotification()。

需要特别指出的是，iOS Safari 完全不支持 PushManager，这意味着 Web Push 在 iPhone 上根本不可用——这不是配置问题，而是平台级别的缺失。

不要用 Notification 掩盖推送链路缺陷

当 WebSocket 断连、SSE 超时、Push 订阅过期时，有些人会添加一层“标题闪烁”或“页面内 Toast”作为 fallback。但这只是视觉上的补救，掩盖了消息根本没有到达浏览器的本质问题。

真正需要下功夫优化的，是消息的抵达率：

• WebSocket 场景：增加心跳 + 自动重连 + 消息队列回溯；
• Web Push 场景：监控订阅 endpoint 过期时间，服务端主动清理失效的 token；
• 移动端 WebView：放弃 Notification API，直接集成原生 SDK（如 HMS Push、MiPush），由容器层统一处理权限和展示。

实际开发中，最容易忽略的关键一步就是：没有等待 navigator.serviceWorker.ready 就急于订阅，结果整个推送链路卡在第一关，还一直以为是通知样式没有配置好。