作为一个前端如果你做过内部管理系统大概率遇到过这样的需求用户不刷新页面就看不到最新的待办、工单、审核结果。桌面通知APINotification API简直是这类需求的一剂猛药——浏览器原生支持不依赖任何厂商推送SDK几行代码就能在访客的桌面上弹出一条系统级通知让用户第一时间看到你发出去的消息。这篇文章不按教科书来我会直接用项目里的真实做法说清三件事权限怎么要、通知怎么弹、坑怎么避。1. 被低估的浏览器能力桌面通知真正适合的场景我第一次认识桌面通知API是在一个工单管理系统里。当时产品提了一个需求有新的工单分派过来页面必须主动提醒用户。第一版实现用的是浏览器标签页标题闪烁加音频播放体验有多差做过的人应该都懂。用户切到别的标签页忙活等回来才发现漏了好几条紧急工单。后来我把方案换成桌面通知效果立刻不一样了无论用户是在写文档、查报表还是把浏览器切到后台屏幕上都会弹出系统级卡片标题、内容、图标清清楚楚点一下还能直接跳到对应工单页。这就是桌面通知API的核心价值它让网页从“被浏览”变成“会主动找人”。前端圈子里很多人觉得这个API太简单不值得单独研究。但真正在生产环境用过就会发现简单的是API不简单的是浏览器的权限策略和生态差异这些细节才是决定功能能不能落地的关键。1.1 我用它替换了“标题闪烁”的工单系统标题闪烁的思路是这样的document.title在“(3) 新工单”和正常标题之间来回切换配合Notification或Audio提醒用户。它能解决问题但代价是用户必须一直停留在当前浏览器标签页一旦切到别的应用信息传递就断了。桌面通知API解决的恰恰是这一步通知直接出现在操作系统层面不需要网页保持可见。在工单系统里我做了这样一条链路登录后请求通知权限WebSocket 接收新工单消息前端在message事件里创建new Notification通知的data字段带上工单 ID点击后跳转到详情页。用户的反馈是“和微信消息提醒很像”老板也满意因为真实响应速度从“下次刷新页面”变成了“当时就能看到”。1.2 四类最适合做桌面通知的业务场景不是所有项目都适合上通知我总结下来这四类场景收益最明显业务场景通知内容示例提醒价值工单/审批系统新工单分配、审批结果返回减少响应延迟避免漏处理数据监控告警指标超阈值、凌晨任务失败不用一直盯着大屏刷新多人协作平台有人你、文档被评论提高协作效率降低信息遗漏发布/运维系统部署成功或失败、定时任务执行完毕释放“人肉刷新页面”的负担这些都是“消息主动找人”的典型场景。反过来如果只是想在页面内部显示一个 toast 提示那就没必要用桌面通知杀鸡不用牛刀。1.3 桌面通知API和推送服务不是一回事这里要先理清一个概念Notification API本身只是“创建并展示通知”的接口它不负责消息从服务器到浏览器的传输。很多前端刚接触时容易混淆以为用了 Notification API用户关掉网页后还能收到推送。其实new Notification()是页面级 API页面活着的时候能弹页面关了就不管用了。要让用户在完全关闭网页后依然收到通知得走 Service Worker Web Push 的方案。关于这部分我在第 6 章会展开说明。所以如果你只想做“用户在当前站点内能收到主动提醒”Notification API 一套就够了如果你想做“用户关掉网站后依然能找到他”那需要把 Web Push 也接上。2. 第一步把权限请求做成用户愿意点“允许”的交互所有通知功能的第一步都是权限。这里有个反直觉的点权限请求其实是最容易做砸的。很多项目直接在页面加载时调用Notification.requestPermission()结果授权率低得可怜。浏览器把这视为骚扰用户也不明白为什么刚打开网页就要“允许通知”。我建议把权限交互当成产品功能来设计而不是当成一行 API 调用。2.1 权限状态机与兼容性探测先写一个兼容探测函数。在部分低版本浏览器或不支持通知的浏览器里Notification对象根本不存在直接调用会报错。function getNotificationStatus() { if (!(Notification in window)) { return unsupported; } return Notification.permission; // granted | denied | default }permission只有三态granted用户已允许可以弹通知。denied用户已拒绝代码无法再次弹原生授权框。default用户还没决定等同于未请求可以调用requestPermission。requestPermission()在老版本浏览器里是回调形式新版本返回 Promise。为了兼容我通常封装成这样async function requestNotifyPermission() { if (!(Notification in window)) { return unsupported; } if (Notification.permission granted) { return granted; } if (Notification.permission denied) { return denied; } // 大部分现代浏览器支持 Promise const permission await Notification.requestPermission(); return permission; }2.2 为什么不能等消息来了才要权限很多业务方会提一个需求等用户第一次收到新消息时再弹出授权框。听起来很合理但实际踩坑了Chrome、Edge 等浏览器把通知权限请求视为“需要用户手势触发”的敏感行为。也就是说requestPermission()必须在用户点击按钮、点击页面等交互事件中调用。如果是在 WebSocket 收到消息后、异步回调里调用浏览器会直接将权限状态设置为denied或者静默拒绝。这就形成了一个死循环业务希望有消息时再要权限但浏览器要求先有用户手势。我当时的解法是在用户登录后打造一个“开启通知”的开关用户主动点击这个开关时再调用requestPermission()。这样既有用户手势又给了用户明确的心理预期。2.3 两段式引导模板我在工单系统里做的引导交互是这样的你可以直接参考首次进入系统时不立即弹原生权限框而是在页面右上角显示一个浮层“开启桌面通知新工单第一时间提醒你”浮层上放一个“立即开启”按钮。用户点击按钮才调用requestPermission()。授权成功后按钮状态变成“通知已开启”拒绝后浮层消失并在系统设置入口提示用户可以从浏览器设置中重新打开。这样做的好处是用户在理解“为什么需要通知”之后再做出决定授权率比重接弹原生框高很多。我在两个项目里对比过粗暴弹原生窗口的授权率不到 20%加了引导浮层后能到 40% 以上。button idenableNotify开启桌面通知/button script document.getElementById(enableNotify).addEventListener(click, async () { const result await requestNotifyPermission(); if (result granted) { // 更新按钮文案和状态 } }); /script还有一个细节https是硬性要求。Notification API属于 Secure Context 的功能在http环境下除了localhost和127.0.0.1都拿不到权限请求资格。如果你在线上测试点击“允许”没反应先检查一下是不是用了 http。3. 第二步创建通知只是 new Notification参数细节没那么简单权限拿到之后创建通知的语法非常简单const notification new Notification(你有新的工单, { body: 工单 #1024 已分配给你, icon: /logo.png, });就这三行桌面上就会弹出一条原生通知。但如果你只是用默认参数体验会差很多。真正让通知“像原生应用”的关键在 options 里。3.1 最小可用代码和基本参数先看一份比较完整的示例const notification new Notification(新的审批请求, { body: 张三提交了采购申请金额5000 元, icon: /icons/icon-192.png, badge: /icons/badge.png, tag: approve-1024, data: { url: /approval/detail/1024, }, requireInteraction: true, silent: false, vibrate: [200, 100, 200], });new Notification的第一个参数是标题第二个参数是配置对象。我用表格列出最常用的选项参数作用使用经验body通知正文控制在两行以内写核心信息icon主图标建议 192x192 以上的 PNGbadge小徽标部分移动端可用显示在图标角落保持简单tag通知分组标签相同 tag 会替换旧通知data自定义业务数据点击通知时能取出来跳转requireInteraction是否常驻不自动消失兼容性有坑见第 5 章silent是否静音提示需要安静场景时可设 truevibrate振动模式毫秒数组只在支持的移动端浏览器生效renotify替换通知时是否重新提醒需要配合 tag 使用3.2 让通知像原生应用可自定义的选项标题和正文是用户最先看到的部分。标题我建议控制在 12 个字以内正文控制在 30 个字以内把最关键的“对象 动作 结果”说清楚。例如“张三 通过了你的请假申请”比“您的请假申请已经被通过”更容易扫读。icon是很多人会忽略但实际体验差别很大的参数。默认不传的话浏览器会显示一个灰色默认图标尽量别用。我一般直接用站点的 logo或者做成一个小尺寸的专门通知图标。如果你的业务有大通知图需求有些浏览器还支持image参数可以在通知右侧放大图。但是image的兼容性参差不齐桌面 Chrome 支持得不错Safari 和 Firefox 不一定理你。在不确定隐私策略的情况下我一般不在通知里放用户敏感信息防止截图流出。silent参数用于不打扰场景。比如凌晨批处理任务完成的通知我会判断当前时间如果落在夜间时段就把silent设为true只弹出卡片不响铃。3.3 给通知加上“业务上下文”data 字段的正确用法data字段最容易被新手忽略但它恰恰是最重要的一个。通知弹出的瞬间用户可能处于任何位置点击通知后我们要把用户带回业务页面靠的就是data。我的统一约定每次创建通知都在data里放一个url字段指向这个通知对应的详情页地址。除了url还可以放id、type、from等识别字段便于做事件统计。const notification new Notification(title, { body, icon, data: { url: /order/detail/1024, id: 1024, type: order, }, });到了事件处理阶段这些数据会被取出来使用。如果这一步提前不规划好后面写onclick的时候会很痛苦。4. 第三步事件处理决定通知是否“好用”通知弹出来只是开始点击、关闭、错误处理才是决定体验的关键。很多项目通知能弹但点了没反应或者关闭后内存泄漏都是事件处理没做好。4.1 点击通知后该做什么点击通知的默认行为是“聚焦到当前标签页”。但业务期望往往是“跳转到某个详情页”所以我们必须拦截默认行为自己控制跳转。notification.onclick (event) { event.preventDefault(); const url notification.data?.url || /; window.focus(); window.open(url, _blank); notification.close(); };这里有几个细节event.preventDefault()会阻止浏览器“只聚焦但不跳转”的行为。window.focus()确保浏览器窗口回到前台。window.open(url, _blank)是业务最常用的打开方式。如果通知关联的详情页需要“在本标签页打开”可以用window.location.href url但我个人更推荐新标签页因为用户可能正在处理另一个事项。点击后要调用notification.close()否则通知会一直留在通知中心用户还要手动清理。4.2 关闭逻辑与内存管理notification实例如果没有被引用不会立即销毁它会在通知生命周期结束后由浏览器回收。但如果我们给onclick、onshow这些回调绑定了闭包又没有及时清理引用就可能造成内存泄漏。尤其在高频通知场景下几百条通知累积下来页面会明显卡顿。一个完整的通知生命周期管理示例function showNotify(title, options, timeout 10000) { if (!(Notification in window) || Notification.permission ! granted) { return null; } const notification new Notification(title, options); let timer null; notification.onshow () { // 默认10秒后自动关闭避免堆积 timer setTimeout(() { notification.close(); timer null; }, timeout); }; notification.onclick (event) { event.preventDefault(); window.focus(); if (options.data?.url) { window.open(options.data.url, _blank); } notification.close(); }; notification.onclose () { if (timer) { clearTimeout(timer); timer null; } }; notification.onerror (err) { console.error(通知展示失败, err); if (timer) { clearTimeout(timer); timer null; } }; return notification; }onerror很关键。权限已经 granted但系统可能因为静音模式、省电模式、隐私设置等原因不允许弹通知出现错误时至少要在页面上留下日志方便排查。4.3 把通知管理模块化而不是到处写 new Notification如果项目里有多个地方会弹通知建议抽成一个通用的通知管理模块。我之前就是一个页面一个new Notification后来发现权限判断、点击跳转逻辑各写一遍还容易漏掉关闭逻辑。抽成一个notify.js之后调用方只需要传标题、正文、跳转地址其余统一处理代码干净很多。// notify.js export function notify(title, { body , url , icon /logo.png } {}) { if (!(Notification in window)) { console.warn(当前环境不支持桌面通知); return; } if (Notification.permission ! granted) { return; } const options { body, icon, data: { url } }; const notification new Notification(title, options); notification.onclick (event) { event.preventDefault(); window.focus(); if (url) { window.open(url, _blank); } notification.close(); }; // 自动关闭避免长期残留 setTimeout(() notification.close(), 10000); }这样整个前端在调用时只需要关心业务数据不用每次都写一堆事件处理。5. 避坑指南七个实战踩坑记录与降级方案这部分是正文里最想让你看到的。上面那些步骤看起来都很顺利但真正投入生产你大概率会遇到下面这些坑我在实际项目里都踩过每一个都有对应的排查思路。5.1 iOS Safari 不支持 new Notification用 SW Push 替代这是桌面通知 API 最大的兼容性边界。在 iOS Safari 上Notification对象存在但new Notification()并不能像桌面浏览器一样弹出系统通知。即使你拿到权限也可能关联到 Safari 自身的行为而不是操作系统通知中心。实测下来iOS 上要让通知落地只能走 Service Worker Web Push并且用户必须先把网站“添加到主屏幕”站点才能获得 Push 权限。注意这和安卓浏览器的要求不一致。所以遇到 iPhone 用户说“通知不弹”不要怀疑代码先问一句“你的站点是不是通过主屏幕进入的”。降级方案检测到 iOS Safari 或非安全上下文时页面内部使用自己的消息中心比如右下角弹层给用户的体验是“虽然没系统通知但不会漏消息”。5.2 安卓手机不弹通知先查系统设置在安卓端Notification.permission返回granted不代表通知一定能显示。因为浏览器层面的通知权限只是第一道门安卓系统还有自己的“应用通知”设置。如果用户在系统设置中关闭了 Chrome 或对应浏览器的通知浏览器内页面无论怎么弹都不会显示。排查路径先看Notification.permission是否 granted如果 granted 但没弹让用户去系统设置检查“通知使用权”和“允许通知”开关。还有一个常见问题是国产手机的自启动限制和后台省电策略会把浏览器后台活动直接杀掉导致通知彻底消失。5.3 权限请求必须在用户手势里否则被静默拒绝这一点在第 2 章提过但值得展开。我在一个数据大屏项目里犯过的错是页面初始化后主动请求权限发现 Chrome 不会弹授权框而且Notification.permission直接变成denied之后无论怎么重试都无法再弹。这就是因为requestPermission()没有用户手势触发浏览器不信任这个请求。正确做法是设计一个“开启通知”按钮让用户手动点击。同时要注意不要在一个 Promise 链的内部调用requestPermission()即使 Promise 的源头是用户点击事件经过多次await后部分浏览器也可能不再认为是用户手势。稳妥起见把requestPermission()放在最直接的 click 事件处理函数里。5.4 requireInteraction 没有想象中可靠requireInteraction: true的语义是通知常驻直到用户手动关闭。听起来很适合重要告警但实际上在部分桌面 Chrome 版本里该参数并不总是生效通知仍会在十几秒后自动消失。Windows 系统的通知中心也可能忽略这个字段。我的应对策略是重要消息不要只靠一条桌面通知。通知弹出的同时在页面内部保留一个持续可见的任务中心/红点用户即使错过了通知也能在回页面时一眼看到。另外对某些高优先级场景可以设置一个setInterval或setTimeout在通知消失后再次提醒但频率一定要克制否则用户会被打扰到直接关掉整个站点权限。5.5 点击通知跳转页面要提前埋好 URL通知的 onclick 事件里拿不到业务上下文除非你在创建时把所有必要数据塞到data字段。踩过的一个具体问题是项目有一个“新订单”通知点击后需要跳转到订单详情但我当时在onclick里直接写死了/order没有用data.url结果所有通知的点击都去了订单列表而不是具体详情页。用户要在列表里再找一次体验大打折扣。另外如果window.open(url, _blank)中的 URL 没有设置或路径错误用户点击通知后页面没有任何反应。建议在通知显示前先本地校验data.url是否存在不存在则降级为聚焦页面。5.6 多标签页同时弹通知的刷屏问题用户在同一浏览器里开多个标签页访问同一系统如果系统在某个标签页收到 WebSocket 推送后创建通知其他标签页也可能各自收到消息并创建通知结果就是操作系统通知中心瞬间涌入几条相同消息。解决思路有两种。第一种使用BroadcastChannel广播让一个标签页作为主标签页只有它弹通知其他标签页只同步数据。第二种将通知展示统一交给 Service Worker页面用 PostMessage 把消息发给 SW 再由 SW 展示。第二种方式更接近标准方案也方便后续扩展 Web Push。5.7 用户点了“阻止”之后代码能做什么用户如果点击了浏览器的“阻止”按钮Notification.permission会变成denied之后无论怎么调用requestPermission()都不再弹窗。前端代码无法再次触发原生授权框只能引导用户去浏览器设置中手动修改站点权限。可以做的事在设置页检测到denied时显示“通知已被浏览器阻止”并提供“去设置”按钮。Chrome 用户可以跳转到chrome://settings/content/notifications但不同浏览器地址不同建议配合浏览器能力检测给出对应的引导文案。页面内部提供降级提醒比如底部横幅或站内信让关闭了系统通知的用户至少不会漏关键消息。6. 进阶用 Service Worker 把“用户离开页面”也变成可用场景如果你想把通知能力做得更完整就要从new Notification升级到 Service Worker 通知。这也是很多人在理解 Notification API 时的知识盲区。6.1 new Notification 和 registration.showNotification 的区别两者核心区别在于运行上下文new Notification运行在页面上下文页面关闭或刷新后当前通知就带不出来。用户离开站点后你再也没有机会调用它。registration.showNotification运行在 Service Worker 上下文由浏览器在后台调度。只要浏览器进程活着用户完全关闭页面后也能收到通知。如果想实现“用户离开网页后消息还能找到他”必须走后面这条路。前端需要先注册 Service Worker然后通过PushManager.subscribe()订阅推送后端配合用 VAPID 协议下发消息。6.2 最小 Service Worker 推送演示注册 Service Workerif (serviceWorker in navigator) { navigator.serviceWorker.register(/sw.js); }在sw.js里监听 push 事件展示系统通知self.addEventListener(push, (event) { const payload event.data ? event.data.json() : {}; const { title, body, icon, url } payload; event.waitUntil( self.registration.showNotification(title, { body, icon, data: { url }, }) ); }); self.addEventListener(notificationclick, (event) { event.notification.close(); const url event.notification.data?.url || /; event.waitUntil( clients.matchAll({ type: window }).then(() { return clients.openWindow(url); }) ); });注意notificationclick事件也发生在 SW 里点击后通过clients.openWindow(url)打开页面这在桌面端表现很接近原生应用。不过Web Push 涉及后端不是纯前端能独立搞定的。如果你只是想在自己项目里先实验可以把推送方简化成“局域网或本机 Node 服务”。但要做生产级别的 Web Push建议专门找后端同事一起定协议进程里踩过的坑会更多比如 VAPID 密钥管理、过期订阅处理等。6.3 生产环境落地建议以目前前端项目的实际情况我给你一个可落地的分级方案用户状态推荐方案说明页面处于打开状态new Notification或 SW 内消息最直接页面上下文可用页面被切到后台但未关闭优先使用页面通知必要时 SW 兜底浏览器可能限制后台标签页的通知频率用户完全关闭站点页面必须用 Web Push SW纯前端 Notification API 无法覆盖iOS Safari 用户只能走 Web Push 且需添加到主屏幕别把常规页面通知当主方案在生产环境我建议把 Notification API 做成一个中间层页面里统一调用封装模块底层根据当前环境选择用new Notification还是registration.showNotification并且预留 Web Push 的接入入口。这样前端业务代码不用关心底层差异后续扩展推送能力也不会伤筋动骨。另外一个经验是桌面通知虽然好用但一定要给用户“随时关闭”的权利。在设置页提供开关并把开关状态同步到本地存储。很多用户对弹通知的反感来自于“无法关闭”的恐惧。只要开关按钮一直在授权率反而会更高。实际用下来桌面通知API最打动我的一点是它让网页终于有了一点“应用感”。它不复杂但每个参数背后都藏着用户习惯和浏览器规范的博弈。如果你也准备在自己的项目里做通知提醒建议先从一个开关加一个封装好的notify函数开始跑通后逐步接入业务场景。等踩过那些版本坑之后再回头看本章的避坑清单应该会更有共鸣。
