能用,但需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、徽标角标或轮询提示
HTTPS、用户授权、Service Worker 这三层缺一不可,少一层就只是个“看着能用、其实发不出去”的幻觉。
