能用，但需HTTPS环境、用户授权且页面未关闭；iOS Safari不支持，推送需Service Worker+Push API配合。
HTML5 Notification API 现在还能用吗
能用，但有严格前提：必须在 HTTPS 环境下运行，且用户已明确授权。HTTP 页面调用 Notification.requestPermission() 会直接拒绝，控制台报错 TypeError: Cannot read property 'requestPermission' of undefined 或静默失败。
- 本地开发时
localhost和127.0.0.1被浏览器视为安全上下文，可测试 - Chrome、Edge、Firefox 支持完整功能；Safari 仅支持 macOS 14+ 且需用户在系统设置中开启“网站通知”
- 移动端（Android Chrome）支持，但 iOS Safari 完全不支持
NotificationAPI
为什么页面没弹出通知，却没报错
常见于权限状态被缓存或误判。调用前必须检查 Notification.permission，它只可能为 "granted"、"denied" 或 "default" —— 后两者都意味着不能发通知。
-
"default"表示用户尚未选择，此时调用new Notification()会静默丢弃，不触发错误也不弹窗 - 用户点过“阻止”，之后即使刷新页面，
permission也永久是"denied"，无法通过代码重置 - 部分浏览器（如新版 Edge）对频繁请求权限会自动降级为
"denied"
if (Notification.permission === "granted") {
new Notification("你好", { body: "这是一条通知" });
} else if (Notification.permission === "default") {
Notification.requestPermission().then(result => {
if (result === "granted") {
new Notification("你好");
}
});
}
Notification API 和服务端推送是两回事
HTML5 的 Notification 只负责「在前台或后台显示一个本地弹窗」，它不涉及网络通信、不唤醒页面、也不依赖服务器。真要实现“用户关闭网页后还能收到提醒”，必须搭配 Service Worker + Push API + 后端推送服务（如 Firebase Cloud Messaging 或 Web Push Protocol）。
- 单纯用
Notification在页面关闭后立刻失效 —— 没有 Service Worker，就没有后台执行环境 -
Push API需要生成 VAPID 密钥、订阅用户、服务端调用推送端点，流程远比Notification复杂 - 浏览器对后台推送有节流：Chrome 可能延迟数分钟才送达，Firefox 更保守；iOS 完全不支持 Push API
实际项目中要不要上 Notification API
适合轻量交互场景，比如表单提交成功、聊天消息到达（页面处于焦点时）、定时提醒（用户开着页面）。不适合替代邮件、短信或 App 推送。
立即学习“前端免费学习笔记（深入）”；
- 别把它当“Web 版微信消息”——没有后台持久化能力，也没有跨设备同步
- 用户首次看到权限弹窗大概率点“阻止”，建议延后触发（如用户点击“开启提醒”按钮后再申请）
- 务必降级处理：权限被拒时改用页面内 Toast、徽标角标或轮询提示
