Web 推送通知服务是什么？工作原理与选型指南（2026）

Web 推送通知服务，是让网站在用户已经离开页面之后、仍然能把一条消息送到用户设备上的那层基础设施。听起来只是一个小功能，实际上牵涉四套彼此必须对齐的系统。大多数人对 Web 推送的困惑，都来自不清楚厂商到底替你接管了其中哪一段。

本文先讲清机制，再回答那个真正的决策：自己搭，还是买一个 Web 推送通知服务；如果买，该比什么。

Web 推送通知服务到底做了什么

Web 推送由两个开放标准定义 —— Push API 与 Notification API，由浏览器实现，不属于任何厂商。这一点很关键：它意味着投递路径是固定的，没有人能卖给你一条更快的通道。

一条通知的完整路径是这样的：

1. 你的站点注册一个 Service Worker：一段即使标签页关闭、浏览器仍会保留的后台脚本。
2. 用户授予通知权限，浏览器生成一份 订阅（subscription）：一个 endpoint 地址加两把加密密钥，与该浏览器安装实例一一对应。
3. 你的服务器把加密后的载荷发到这个 endpoint，而 endpoint 属于浏览器推送服务（Chrome 走 FCM、Firefox 走 Mozilla autopush、Safari 走苹果的推送服务）。
4. 推送服务在设备上唤醒 Service Worker，由它调用 showNotification() 把通知画出来。

Web 推送通知服务并不替换第 1–4 步，它是把这几步包起来：替你存订阅、管理 VAPID 密钥与载荷加密、对失败的 endpoint 做重试、记录通知的展示与点击，并提供一套分群和定时发送的界面。投递本身，仍然走所有人共用的那几个浏览器推送服务。

这是评估厂商之前最值得先弄明白的一件事。所谓"送达率更高"，绝大多数指的是订阅卫生做得好 —— 及时清理失效 endpoint、正确重试、发送时机合理 —— 而不是拿到了什么特权通道。

自建 vs 采购

自建 Web 推送是完全可行的。Node 的 web-push、Python 的 pywebpush 以及各语言的同类库，几十行代码就能把 VAPID 签名和载荷加密处理掉。如果你只是给一类人群发一种通知，这可能就够了。

代价出现在后面，而且基本不在"发送"这段代码上：

• 订阅生命周期：endpoint 会静默失效。用户清站点数据、重装浏览器、撤销权限，都会让订阅死掉。不做清理，订阅数就会和现实脱节，每次发送都在往死地址上打请求。
• 各浏览器的差异：载荷大小上限、TTL 语义、系统对唤醒的批处理策略，Chrome、Firefox、Safari 各不相同。每一处差异，都是一个等着你在生产环境里发现的小 bug。
• 分群与定时：要发给"看过商品页但没下单、且处于本地时间傍晚"的用户，这是数据问题，不是推送问题 —— 而它恰恰是真正耗时间的部分。
• 数据回收：送达、展示、点击、忽略是四种不同事件，其中只有一部分能从浏览器侧观测到。

一个比较实在的判断标准：推送只是一个事务性触发器，就自建；推送是一条你打算持续分群和迭代的渠道，就采购。

选 Web 推送通知服务时该比什么

平台覆盖。 要专门问 macOS 上的 Safari，以及 iOS 上已安装的 Web 应用。iOS 只对用户添加到主屏幕的 PWA 支持 Web 推送，普通 Safari 标签页不支持。如果厂商给你一个笼统的"全浏览器覆盖"数字，它多半绕开了这条渠道最大的缺口。安装态相关的机制，可以看我们这篇 Android 上的 PWA 推送通知。

授权流程的可控性。 系统权限弹窗实际上只有一次有效机会。用户拒绝之后就结束了 —— 想挽回，得让用户自己翻进浏览器设置。值得付费的服务，都应该允许你先用自己的软提示做前置，并让你自己决定触发时机，而不是页面一加载就弹。

数据归属与导出。 能否导出原始订阅记录与事件日志，还是只能看聚合报表？这决定了将来换厂商是花一周，还是把整个订阅盘子丢掉。

分群模型。 看分群是基于你传进去的事件计算，还是只基于厂商自己的站内埋点。前者能和你现有的数据栈组合，后者会造出第二个、并且必然会分叉的事实源。

计价形态。 按订阅数计价，会惩罚你留存不活跃订阅；按发送量计价，则惩罚发送频次。两者都不算错，关键是和你真实的使用方式匹配。

投递卫生。 问清楚失效 endpoint 怎么清理、失败怎么重试。这是厂商之间真正有差别的地方 —— 因为这类工作不好看、永远不会出现在功能列表上。

Web 推送与应用安装的关系

Web 推送常被当成"更便宜的 App 推送替代品"来评估。更准确的理解是：它是同一条曲线上的另一个点 —— 没有商店审核、没有下载摩擦、不需要安装步骤，但换来的是更弱的授权、更紧的载荷限制，以及除非用户主动安装 Web 应用、否则不会出现在主屏幕上。

如果你想把这个取舍放回整条分发链路（而不只是消息层）去看，可以参考 PWA 与 APK 的对比。

投入之前该知道的边界

• 授权率本来就低。 个位数到十几个百分点的接受率是常态。渠道规模要按流量的一小部分来规划，不能按全量算。
• 权限疲劳是真实的，而且不可逆。 首屏就弹的权限请求转化更差，还会把唯一一次机会烧掉。
• 通知不保证送达。 设备离线超过 TTL，消息会被丢弃，不会无限期排队。
• 载荷很小。 按"一个标题加一行字"来设计，不要按一段话。
• 合规要求同样适用。 推送授权与邮件授权是两回事，且在多个司法辖区，撤回的难度必须与授予时相当。

常见问题

我到底需要 Web 推送通知服务，还是直接用 FCM 就行？

FCM 是投递路径里的浏览器推送服务之一 —— Chrome 那一个。直接用它，你仍然要自己存订阅、加密载荷、清理死 endpoint，并且还要分别对接 Firefox 与 Safari 各自的服务。Web 推送通知服务是它们之上的一层，不是其中任何一个的替代品。

Web 推送在 iPhone 上能用吗？

能，但仅限用户已添加到主屏幕的 Web 应用。普通 Safari 标签页里不生效。所以"安装引导"和"iOS 推送"是同一个决策的两半，不是两个独立功能。

没人退订，订阅数为什么自己掉了？

几乎都是失效 endpoint 被清理掉了。用户清站点数据、重装浏览器，或设备长期闲置到推送服务把 endpoint 判为无效，订阅就会死亡。一个从不下降的订阅数，说明它根本没在做清理。

能给没访问过我网站的人发 Web 推送吗？

不能。订阅只能由那个具体的浏览器、在你的域名下经过明确授权后创建。没有任何途径可以从别处采买或导入订阅者。

怎么选才算理性

先判断推送对你是触发器还是渠道。是触发器，用开源库自建是合理且长期成立的答案；是渠道，就按订阅卫生、授权弹窗可控性、数据可导出这三点去评估 —— 它们都是事后极难补救的部分 —— 同时把首页上那个送达率数字，当作信息量最低的一项来看。