HTML通知与消息推送有关，消息推送可以通过JavaScript触发HTML通知。

HTML通知（Notification API）本身并不等同于消息推送，它仅负责在浏览器中显示通知，而真正的“关页后仍能接收提醒”能力必须依赖Web Push技术——由Service Worker通过pushManager订阅、后台推送服务传递消息，并在onpush事件中调用showNotification()来最终呈现；整个流程严格依赖HTTPS、用户主动授权（不能自动触发）、Service Worker激活状态及正确配置的VAPID密钥，且需持续维护动态失效的推送endpoint，稍有疏漏（如遗漏event.waitUntil、权限为"default"、iOS兼容性或协议/环境限制）就会导致静默失败——这是一套环环相扣、隐私优先、平台差异显著的现代Web通知体系。

HTML通知（Notification API）和消息推送（Web Push）不是一回事，但必须配合使用才能实现“关页后还能收通知”。 单独用 Notification 只能在页面开着时弹窗；真要跨页面、后台、甚至浏览器关闭后发提醒，必须走 Web Push 流程——而 Notification 是最后一步“显示”的唯一标准接口。

为什么 Notification.requestPermission() 总是返回 "default"

这不是 bug，是浏览器的隐私保护机制：用户没明确点过“允许”或“禁止”，就永远卡在 "default"，此时调用 new Notification() 会静默失败，控制台也无报错。

• 必须由用户**主动触发**的事件（如按钮点击）中调用 Notification.requestPermission()，不能 onload 自动执行
• 不能在 HTTP 协议下使用（必须 HTTPS 或 localhost），否则直接拒绝请求
• iOS Safari 完全不支持该 API，连 Notification.permission 都是只读 "denied"
• 如果用户之前点过“阻止”，需手动进浏览器设置里清除站点权限，requestPermission() 不会再弹窗

pushManager.subscribe() 失败的常见原因

这是 Web Push 的核心动作，但它依赖前置条件全部满足。只要一个环节断掉，就会报 TypeError: Failed to execute 'subscribe' on 'PushManager' 或直接返回 undefined。

• Service Worker 必须已成功注册且处于 active 状态——检查 navigator.serviceWorker.ready 再调用订阅
• 当前页面协议必须是 HTTPS（生产环境），http://localhost 是唯一例外
• VAPID 公钥没传给 subscribe() 的 applicationServerKey 参数，或密钥格式不是 Uint8Array（Base64URL 解码后需转成 ArrayBuffer）
• 浏览器推送服务不可用：Chrome 依赖 FCM，国内部分网络可能无法连接；Firefox 需要 autopush 正常响应

serviceWorker.onpush 收到消息但不显示通知？

收到推送事件 ≠ 自动弹窗。Service Worker 里必须显式调用 self.registration.showNotification()，而且得在 event.waitUntil() 里包裹 Promise，否则事件会被提前终止。

• 别漏掉 event.waitUntil()，否则通知可能一闪而过或根本不出现
• showNotification() 的第一个参数是 title，第二个是 options 对象；icon 路径必须是 HTTPS 或相对路径（不能是 blob: 或 data:）
• 如果传了 tag，同 tag 的新通知会替换旧通知；不设 tag 则每次都是独立通知
• 移动端 Chrome Android 支持 badge 字段，但 iOS 完全忽略所有推送相关 API

真正容易被忽略的是：Web Push 的 endpoint 地址有效期不固定，可能几周或几个月就失效，用户重装浏览器、清缓存、换设备都会导致订阅丢失——后端必须把订阅更新当作常态处理，而不是一次写库就完事。

到这里，我们也就讲完了《HTML通知与消息推送有关，消息推送可以通过JavaScript触发HTML通知。》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！