HTML仅是容器，真正实现消息推送需JavaScript的Notification API（仅前端通知显示）和Web Push（需ServiceWorker+PushManager+后端支持）。
HTML 本身不能“配合”消息推送——它只是容器，真正起作用的是 JavaScript 的 Notification API 和 PushManager + ServiceWorker 两套机制。前者是用户在页面内点击后弹出的桌面通知（无需后端），后者才是真正的“消息推送”（需 HTTPS、服务端参与、能唤醒后台）。很多人混淆这两者，结果卡在 Notification.requestPermission() 没反应，或以为发了 new Notification() 就等于实现了 Web Push。
Notification API 能做什么、不能做什么
它只负责“显示通知”，不负责“接收远程消息”。调用 new Notification() 是同步触发，只要权限是 granted，立刻弹窗；但一旦用户切走标签页、关闭浏览器，这个调用就完全失效。它不依赖网络、不涉及加密、不需要 VAPID 密钥。
- 必须由用户手势（如
click）触发首次Notification.requestPermission()，自动执行会静默失败 - 权限状态只有三种：
granted、denied、default；default表示还没点过，下次还得再申请 -
icon路径必须可被浏览器直接 fetch 到（404 会导致图标不显示，但通知仍弹出） - iOS Safari 完全不支持该 API，连
'Notification' in window都返回false
Web Push 必须经过 Service Worker
所谓“消息推送”，是指服务器主动把消息推到用户设备上，哪怕网页没打开。这一步 HTML 一丁点都插不上手：index.html 只负责加载 JS、绑按钮；sw.js 才是真正干活的——它被浏览器常驻在后台，监听 push 事件，然后调用 self.registration.showNotification()。
-
navigator.serviceWorker.register('/sw.js')必须用根路径注册，否则 Chrome/Edge 可能拒绝激活 -
sw.js文件必须至少监听push事件，并在回调里调用event.waitUntil()包裹showNotification()，否则通知不会显示 -
pushManager.subscribe()报InvalidStateError？八成是 SW 还没激活，或者没加skipWaiting()和clients.claim() - 订阅成功后拿到的
endpoint是一次性 URL，有效期通常为数月，但用户清除浏览器数据后立即失效
VAPID 密钥配错是后端推送失败的头号原因
前端传给 subscribe() 的 applicationServerKey 是 Base64URL 编码后的公钥；后端签名时用的必须是同一对密钥的私钥。两者不匹配，推送请求会直接被推送服务（如 FCM、Mozilla Autopush）拒收，错误信息通常是 401 Unauthorized 或 400 Bad Request。
立即学习“前端免费学习笔记（深入）”；
- 公钥必须是
Uint8Array格式，不是原始 PEM 字符串；用urlBase64ToUint8Array()转换后再传 - 后端
Authorizationheader 必须是WebPush xxx格式，xxx 是 VAPID 签名生成的 JWT token - payload 必须加密（AES-GCM），明文 POST 会被拒绝；推荐用
web-push（Node.js）或pywebpush（Python）这类封装库，别手写加密逻辑 - Chrome 120+ 对未激活的 SW 唤醒更苛刻：如果用户长时间没访问你的站点，
push事件可能根本不会触发——这不是代码 bug，是浏览器策略
最易被忽略的一点：Web Push 的整个链路是单向且异步的。你调用 pushManager.subscribe() 成功，不代表后端就能立刻推送；后端 POST 成功，也不代表用户一定能收到通知——中间隔着浏览器推送服务、网络状态、SW 是否存活、用户是否禁用了通知权限。调试时不要只盯前端 console，得查 SW 的 console.log、后端响应 status、甚至用 curl -v 直接模拟推送请求看返回头。
