浏览器推送通知：目录站的 Web Push 该不该做，权限该怎么要
浏
订阅邮件的打开率这两年一直在掉，尤其是那种每周一发的目录更新。于是总有人问：能不能改成浏览器推送？
能做，但先要把覆盖范围搞清楚。Web Push 不是「所有浏览器都能收」，它的实际可用面比大多数人想的窄，尤其是国内以移动端为主的情况下。
图片来源：网络，版权归原作者所有，侵权请联系删除
先看清覆盖面
| 环境 | 能不能订阅 | 前提条件 |
|---|---|---|
| 桌面版 Chrome、Edge、Firefox | 可以 | HTTPS 加服务工作者 |
| 安卓 Chrome | 可以 | 同上 |
| iOS 与 iPadOS 上的 Chrome、Firefox | 不支持 | 这两家在 iOS 上用的是系统内核，不开放推送能力 |
| iOS Safari 标签页 | 不支持 | 推送接口未开放 |
| iOS 添加到主屏幕后的应用 | 可以 | 系统 16.4 以上，且必须从主屏幕图标启动 |
| macOS Safari | 可以 | 16 以上版本 |
看明白这张表，就能算出自己的实际触达率。目录站的流量如果七成来自手机、其中一大半是 iPhone，那么推送能覆盖到的可能只有剩下那一小部分安卓用户加上少数桌面用户。
这不代表不值得做，只是别把它当成邮件或站内消息的替代品。它是多出来的一条通道，不是现有通道的升级版。
三条硬约束
- 必须 HTTPS——服务工作者只在安全上下文里注册，这是前提中的前提。
- 权限请求必须由用户手势触发——不能在页面加载时直接弹。苹果的文档写得很明确：要提供一个按钮之类的入口，用户点了之后，在手势的事件处理里立刻调用订阅方法。页面一进来就弹权限框，用户几乎必然点拒绝，而且拒绝之后很难再要第二次。
- 苹果平台没有静默推送——服务工作者收到消息后必须立刻展示出来，不展示的话，系统会直接撤销这个站点的推送权限。同样的代码在 Chrome 上只是没反应，在 Safari 上会导致权限被收回，这是最容易踩的一个坑。
服务端这边要准备 VAPID 密钥对，用来向推送服务表明身份；每条消息加密传输，推送服务本身读不到内容。消息里可以带有效期，设备离线时推送服务会暂存一段时间（各家上限不同，一般按天计算），过期就丢弃。
什么时候要权限
不要在一进站就要。用户还不知道你这个站有什么用，此时弹权限框，拒绝率极高。
合理的时机是用户已经表现出明确兴趣之后：收藏了几个条目、订阅了某个分类、或者提交了一个站点。在这些动作完成之后顺带问一句「有新条目时通知你」，接受率会高出一个量级。
还有个技巧是先在页面内放一个自己的提示条，用户点了再走浏览器原生弹窗。原生弹窗只有一次机会，前面的提示条可以反复出现，被关掉也没损失。
目录站值得发的三种消息
- 用户订阅的分类有新条目——定向、有明确价值，用户点了订阅就说明想要
- 用户收藏的站点状态变化——失效、易主、重新上线，这类信息用户很难自己发现
- 提交条目的审核结果——和邮件互补，一条就够，别重复发
不值得发的是「本周精选」这种汇总。它不针对具体用户，价值等同于营销邮件，发几次之后就是批量关闭权限。推送比邮件更侵入，用户对它的容忍度也更低，一次骚扰的代价是永久失去这个通道。
别忘了退订和失效清理
推送订阅会失效：用户换了设备、清了浏览器数据、或者卸载了主屏幕图标。服务端要处理推送返回的错误码，把失效的订阅从库里删掉，别一直往空地址发。
退订入口也要有。站内设置里放一个开关，比让用户去系统设置里关要友好得多，也能保住这个用户以后再打开的可能。
最后回到那个问题：该不该做。如果你的站有明确的高价值时刻（用户提交后等结果、收藏的站点有变化），值得做；如果只是想多一个推送渠道发周报，那不如把周报本身写好一点。