html通知仅负责显示，不负责消息送达；真正推送依赖websocket或service worker+push api，且需用户授权、https环境及后端web push协议支持。
HTML通知本身不能替代消息推送，它只是推送链路的最后一步显示层。 真正决定“能不能推”“推不推得过去”的，是底层通信机制（如 WebSocket、Service Worker + Push API），而不是 new Notification() 这行代码。
Notification API 只负责“弹出来”，不负责“送过来”
很多人误以为调用 new Notification() 就等于实现了推送——其实它连网络请求都不发。它只在浏览器已拿到消息数据后，才负责渲染成桌面通知。
- 必须先有数据：要么靠前端轮询
/api/messages，要么靠 WebSocket 主动收，要么靠 Service Worker 接收 Web Push 消息 - 必须有权限：
Notification.requestPermission()得用户点过同意，且仅对当前页面生效 - 必须在安全上下文：HTTP 站点直接报错，
Notification构造函数会抛TypeError: Notification permission denied - iOS Safari 完全不支持，Android Chrome 从 2024 年起默认禁用非用户触发的通知
想“真正推送”，得看你是要“在线实时”还是“离线可达”
这是最关键的分水岭，选错方案会导致功能完全不可用：
- 用户开着网页、聊天窗口没关 → 用
WebSocket+Notification组合最稳：连接活着，消息秒达，onmessage触发后立即new Notification() - 用户关了标签页、切到其他 App、甚至关机再开机 → 必须走
Service Worker+PushManager+ 后端 Web Push 协议（VAPID）：只有 Service Worker 能在后台被唤醒并调用showNotification() - 别试图用
setTimeout轮询 +Notification模拟推送：移动端会被系统休眠策略杀死定时器，iOS 尤其明显；服务端也扛不住高频请求
常见错误：把标题闪烁当推送，还配了个“已开启通知”假开关
微博 H5、很多企业后台都这么干——页面失焦时疯狂改 document.title，然后 UI 上显示“消息提醒已开启”。这根本不是推送，只是视觉骚扰。
- 用户没授权
Notification.permission，你连new Notification()都执行不了，更别说弹窗 - 你写的“开启按钮”如果只是改个本地变量，没调
Notification.requestPermission()，那等于没申请 - 权限状态是全局的：
Notification.permission === 'default'时，每次调用requestPermission()都会弹系统框；但用户点“阻止”后，后续调用直接 resolve 为'denied'，再不会给机会 - 测试时记得清空权限：Chrome 地址栏点锁图标 → “网站设置” → 找到你的域名 → 重置通知权限
Service Worker 是离线推送唯一可行路径，但它有硬门槛
想让消息在用户关掉网页后还能抵达，绕不开 Service Worker。但这东西不是加个 JS 文件就完事：
- 必须 HTTPS（
localhost除外），HTTP 站点注册会静默失败 - 注册脚本必须在主页面 JS 中执行：
navigator.serviceWorker.register('/sw.js')，且不能放在模块脚本里（type="module"） -
sw.js文件必须能被直接 GET 访问，返回Content-Type: application/javascript，任何 302 重定向或 404 都导致注册失败 - 首次注册后，
sw.js更新不会立即生效：新版本要等下次页面加载时激活，期间仍运行旧版逻辑 - 调试困难：Chrome 的 Application → Service Workers 面板里要勾上 “Update on reload” 和 “Offline”，否则看不到实时效果
最常被忽略的一点：Web Push 不是免费的“发短信”。你要自己搭后端对接 Google FCM 或 Mozilla Autopush，或者用第三方服务（如 OneSignal、Pushy），还要处理 VAPID 密钥、订阅存储、失效端点清理——这些工作量远超写几行 new Notification()。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
