浏览器通知需用户交互授权且依赖HTTPS，Notification API须绑定点击等动作调用，Web Push需Service Worker、VAPID及后端加密推送，iOS Safari不支持；桌面通知与页面Toast须分开设计，降级方案为标题闪烁+Toast。
浏览器里弹出的通知，不是靠前端“主动刷”出来的，而是得先拿到用户授权、再走系统级通道；不区分场景硬套 Notification API，大概率被拦截或静默丢弃。
Notification API 必须在用户交互后调用
浏览器禁止页面一加载就弹权限框，否则会被直接屏蔽。哪怕你写了 Notification.requestPermission()，只要没绑定到按钮点击、键盘输入这类明确的用户动作上，Chrome 和 Edge 会直接返回 "denied"。
- 正确做法：只在用户点击「开启消息提醒」按钮后触发请求
- 错误写法：
window.addEventListener('load', () => Notification.requestPermission())—— 这种自动触发几乎必失败 - 权限状态只有三种：
"granted"、"denied"、"default"；"default"表示还没点过，下次还能再试，但别反复弹
Web Push 需要 Service Worker + VAPID + 后端配合
想关掉网页还能收到通知？光靠 Notification 不行，必须走 Web Push 流程。它依赖后台长期运行的 Service Worker 接收加密推送，而前端只是注册和订阅的入口。
- 前端必须先注册
service-worker.js，且该文件需部署在 HTTPS 或localhost下 -
pushManager.subscribe()调用时必须传入 VAPID 公钥，否则 Chrome 会报错"Failed to execute 'subscribe' on 'PushManager': Subscription failed - no valid key provided" - 后端不能直接发明文消息，得用
web-push库 + VAPID 私钥，向浏览器返回的endpoint发送加密 POST 请求 - iOS Safari 完全不支持 Web Push，连
Service Worker都受限，别在这上面浪费调试时间
桌面通知和页面内提示得分开设计
很多人以为 Notification 是万能弹窗，其实它只管操作系统层的桌面通知。用户切走标签页、最小化浏览器、甚至关掉网页，都可能收不到——因为 Service Worker 没启用，或者没走 Web Push。
立即学习“前端免费学习笔记（深入）”；
- 高频操作反馈（如「保存成功」）应该用页面内
Toast，靠 CSS 动画 + DOM 操作实现，无需授权、兼容性好 - 真正重要的异步事件（如聊天新消息、审批通过）才走
Notification，且必须搭配onclick回调跳转到对应页面，否则用户点了没反应，体验直接归零 - 当
'Notification' in window为false或权限是"denied"时，降级方案不是“不提示”，而是改用标题闪烁 + 页面右下角Toast，至少保底可见
最常被忽略的一点：所有推送链路都强依赖 HTTPS。HTTP 站点连 Service Worker 都注册不了，更别说 Notification.requestPermission() 会直接拒绝。本地开发用 localhost 可以绕过，但一上测试环境就暴露问题。
