notification api 不能实现离线推送，必须配合 push api 和 service worker；需 https、用户授权、后端加密推送及 endpoint 管理才能完成可靠消息链路。
HTML 通知（Notification API）不能替代服务端消息推送，它只是前端展示层的轻量提醒机制，依赖页面存活或 Service Worker 持久化支持；真要实现“应用关闭时也能收消息”，必须搭配 Push API + 后端推送服务（如 Firebase Cloud Messaging、Web Push Protocol）。
为什么 Notification API 单独用不了离线推送
浏览器对未激活标签页或关闭状态的页面会限制 JS 执行——这意味着：new Notification() 在页面没打开时根本不会运行。
- 仅当网页处于前台、后台（含最小化但标签页未被冻结）或通过
Service Worker触发时，才能显示通知 -
Notification本身不包含网络请求能力，它不拉消息，只负责渲染你给它的内容 - Chrome/Firefox 等现代浏览器要求站点必须是 HTTPS（
localhost除外），否则Notification.requestPermission()直接拒绝
如何让通知真正“推”到用户面前
核心路径是：服务端发送 push 消息 → 浏览器触发 push 事件 → Service Worker 调用 self.registration.showNotification()。
- 必须注册并激活一个
Service Worker，且其作用域覆盖整个站点（通常放在根目录） - 用户需先调用
Notification.requestPermission()授予权限，之后才能订阅PushManager - 订阅成功后，前端拿到
endpoint（类似设备 token），需上传至你自己的后端，用于后续调用webpush库发送加密 payload - Service Worker 中监听
push事件时，注意处理空 payload 或无效 JSON，否则会触发unhandledrejection
showNotification() 的实际调用要点
这是 Service Worker 内真正弹出通知的函数，不是在主页面里调用的。
- 第一个参数
title是必填字符串，第二个参数options可传body、icon、badge、data（用于点击跳转）、actions（按钮）等 -
icon建议用绝对路径（如/img/icon-192.png），相对路径在 SW 环境中容易 404 - 若想点击通知后跳转到特定页面，需在
data里存 URL，并在notificationclick事件中用clients.openWindow()打开 - 不要在
showNotification()中直接执行耗时操作（如 fetch），它应在事件响应中快速完成，异步逻辑放到notificationclick或其他事件里
常见失败场景和绕不过去的坑
很多“通知不弹出来”的问题，其实卡在权限、证书或生命周期上。
- 开发阶段用
http://localhost可以跑通，但部署到http://xxx.com会静默失败——必须换 HTTPS - Chrome 对频繁弹通知有节流：同一域名 1 分钟内最多触发几次，超出则丢弃，且不报错
- Firefox 要求
manifest.json中声明gcm_sender_id（旧版）或使用 VAPID keys（新版），否则pushManager.subscribe()报InvalidStateError - Android Chrome 有时会把 Web Push 归类为“系统通知”，用户手动关闭“网站通知”开关后，
permission状态变成denied，此时再调requestPermission()也不会弹窗，只能引导用户去浏览器设置里手动开启
真正难的不是写几行 showNotification()，而是把权限流、订阅管理、密钥分发、后端加密推送、失效 endpoint 清理这些环节串成一条可靠链路。其中任意一环断掉，用户就收不到——而这些问题在线上环境往往没有明确错误提示。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
