一封不会迷路的信：Push通知与Web Notifications全解

可视化演示

演示Web Push推送服务注册、订阅生命周期、消息载荷加密与通知交互，理解权限策略与跨浏览器兼容。

概念辨析：邮递员与信，是两回事

常去咖啡馆寄信，你得先分清两样东西：一个是骑着车跑腿的邮递员，一个是你手里拆开的那封信。Web 世界里，Push（推送）就是那个邮递员，负责把消息从服务器“主动”送到浏览器；Web Notification 则是你眼前展开的信纸，负责把内容展示给用户。它们是两个独立 API，却总被初学者混为一谈。

为什么需要分工？因为“投递”和“展示”的时机完全不同。Push 消息可以在页面关闭、浏览器退到后台时悄悄抵达；而展示必须发生在“用户看得到”的界面层。于是浏览器设计了一个中间人——Service Worker，它常驻后台，负责签收推送消息，再调用 Notification API 把内容弹出来。

完整链路是：应用服务器把消息 POST 到推送服务，推送服务按订阅地址投递到用户设备，浏览器唤起 Service Worker 的 push 事件，事件回调里调用 self.registration.showNotification(...) 展示通知。三者各司其职：Push 管“怎么送到”，Service Worker 管“何时接收”，Notification 管“如何呈现”。

所以下次有人说“我收到了推送”，你可以追问一句：“是邮递员到了，还是信纸已经摊开了？”只有 Push 投递加上 Notification 展示首尾衔接，才构成完整的通知体验——这也是 PWA 离线和后台场景下最常用的组合拳。

订阅生命周期：先登记地址，邮路才能通

邮局寄信有个前提：它得先知道你的地址。Web Push 里，这个“登记地址”的动作叫订阅（subscribe）。用户首次打开页面，应用调用 pushManager.subscribe()，浏览器便生成一个独一无二的 PushSubscription 对象——这就是你的“电子门牌号”。

这个门牌号包含三件套：endpoint 是投递端点，相当于“XX路XX号”；p256dh 是公钥，相当于信箱的锁；auth 是认证密文，相当于备用钥匙。应用拿到订阅后要立刻 POST 给自己的服务器保存。服务器推送消息时，就靠 endpoint 作为收件地址，靠 p256dh 加密内容。

有生就有灭。用户可能关停账号、清除站点数据，浏览器也可能回收失效订阅。取消订阅时前端调用 subscription.unsubscribe()，同时必须请求服务器删除对应记录；服务器推送时若收到 404/410 响应，说明地址已废弃，也应主动清理。订阅还会过期（expirationTime），需要监听并自动“续订”，保持邮路畅通。

把订阅想象成一份“寄信契约”再合适不过：前端退订而服务端不删，就像你搬了家却忘了通知杂志社，广告照样寄往空屋，白费纸张。真正的工程实践里，收到 410 状态码主动清理订阅表，是每个推送系统必须写进代码里的“邮差自觉”。

消息加密机制：给信里加一道双人锁

寄机密信件时，你会担心邮递员偷看。最简单的办法是买一把“双人锁”：只有你和收信人各持一把钥匙，才能共同打开铁盒，途经的邮递员只能看到盒子，看不到一个字。Web Push 的加密正是基于这个智慧——推送服务可以送信，但永远读不了信。

加密的第一步是身份认证。应用服务器用 VAPID 协议生成一对公钥/私钥：私钥在服务器上对 JWT 令牌签名，推送服务验证签名后确认“寄信人是真的”，再放行。没有这一步，任何人都能冒用你的名义给用户推送垃圾信息，相当于伪造寄件人地址。

第二步是密钥协商与加密。服务器取订阅里的 p256dh 公钥，与自己的私钥做 ECDH 椭圆曲线协商，得到一个双方共享的会话密钥；再用 AES-128-GCM 对消息载荷加密。数据到达设备后，Service Worker 用同样的共享密钥解密，再展示通知。整个过程推送服务只能转发密文，无法读取内容，实现端到端保密。

记住：推送服务是“邮局”，可以看信封上的地址，却永远不该看到信里的内容。凡是把消息明文交给推送服务的做法，都相当于把情书贴在明信片上寄出——用户数据和隐私安全，全靠这一层加密守护。

通知交互流程：信到了，然后呢？

信送到你手上之后，剧情才刚刚开始：你可能拆开细读（点击），可能顺手夹进书里（留存），也可能看都不看丢进垃圾桶（关闭）。Web Notifications 用事件机制把这三类反应一一记录下来，让开发者能精准回应。

应用在 Service Worker 里调用 showNotification 时，可以指定 title、body、icon 等外观，还能塞一个 data 字段，把“这封信来自哪个订单”之类的上下文带进去。用户点击通知时，浏览器触发 notificationclick 事件，回调里通过 clients.matchAll() 找到已打开的页面窗口并调用 focus() 聚焦；如果没有窗口，则 clients.openWindow() 新开页面直达详情。

通知还可以带 actions 按钮（如“查看”与“忽略”），点击不同按钮会携带不同的 action 值，供回调区分处理。实践中常用 tag 字段对通知分组（同一 tag 的通知会合并替换），用 renotify 控制是否再次提醒，避免满屏轰炸；展示时机则应选在用户可能注意到的时刻，避开深夜打扰。notificationclose 事件则负责“用户手动划掉通知”这类清理动作。

交互设计上，好通知像一扇门：用户点一下就能到达想去的地方。如果通知点击后只是“哦我知道了”，甚至点了没反应，用户很快会把它划掉，你的邮路也就彻底失宠了——所以 data 带上文、action 给选项、tag 做分类，是三件必须养成的习惯。

权限策略：别在人家门口硬塞广告

想象一个推销员，见面第一秒就掏出喇叭喊“办卡吗”——你大概率关门。但如果他先在店门口放一杯免费试饮，等你尝了觉得不错，再问“要不要留个地址寄优惠券”，成交率就高得多。通知权限的请求，正是这个“要地址”的瞬间。

浏览器规定 Notification.requestPermission() 必须在用户手势（例如点击按钮）触发的代码路径里调用，才会弹出权限询问框。权限状态只有三种：granted（已授权）、denied（已拒绝）、default（未询问）。一旦用户选择“拒绝”，浏览器不再弹出询问框——这就像邮局把那个推销员拉进了黑名单。

所以工程上要讲究策略：先用站内引导让用户理解“订阅后能得到什么”，再在恰当时机（如用户完成一次有价值操作后）请求权限；被拒绝后不要反复轰炸，而是提供“重新开启”的站内说明，引导用户去浏览器设置中手动打开。收到推送后还要监测送达率，如果用户长期不点击，应主动降低推送频率，避免“邮件疲劳”。

权限的本质是“用户把家门钥匙交给你”的信任决定。尊重这个决定，在它不点头时不硬塞、被拒绝后不纠缠、拿到授权后克制地使用，你的邮路才能长久畅通——这也是为什么产品设计里“请求权限的时机”往往比“推送的内容”更决定成败。

跨浏览器兼容：各国有各国的邮规

出国寄信前你得研究当地邮规：有的国家要贴邮票、有的要填税号、有的周末不送。浏览器世界同样如此：Chrome 用自己的 FCM 做推送服务，Firefox 用 Mozilla 自建服务，Safari 直到 16.4 才完整支持 Web Push，而且要求用户先把站点加入程序坞或主屏幕。无视这些差异，你的“邮路”可能在某个浏览器上直接断掉。

工程上的第一道防线是特性检测：注册 Service Worker 前先确认 'serviceWorker' in navigator，再确认 'PushManager' in window 与 'Notification' in window。三者全部为真才走推送流程，否则降级为站内消息、邮件等替代方案，保证核心通知能力不断档。

具体差异要逐个击破：旧版 Chrome 需要 manifest 里的 gcm_sender_id；Firefox 与 Chrome 的订阅端点格式不同，服务器要用统一的 web-push 库封装；Safari 的权限请求 UI 与桌面端不同，需要额外的“添加到主屏幕”引导。调试时，Chrome DevTools 的 Application 面板可以手动触发 push 事件、查看订阅详情、模拟离线，是排查“信为什么没送到”的利器。

兼容性的心法是“先查路况、再定路线”：能走大路（标准 API）就走大路，不能走就抄小路（降级方案），永远别让用户因为浏览器不同而收不到信。把特性检测写成应用的第一道关卡，把降级方案做成最后的底线，这才是一个成熟工程师该有的邮局思维。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""Simulate the Web Push pipeline: permission, subscribe, encrypt, deliver, unsubscribe."""  class PushClient:    def __init__(self, user_id):        self.user_id = user_id        self.subscription = None  # 已登记的收信地址        self.permission = 'default'  # 权限三态: granted/denied/default     def ask_permission(self, yes=True):        if yes:            self.permission = 'granted'        else:            self.permission = 'denied'        return self.permission     def subscribe(self, endpoint, public_key, auth_secret):        if self.permission != 'granted':            raise RuntimeError('No permission, cannot subscribe')        self.subscription = {            'endpoint': endpoint,            'p256dh': public_key,            'auth': auth_secret,        }        return self.subscription     def unsubscribe(self):        self.subscription = None  class PushService:    """Forward node between the app server and the browser."""     def __init__(self):        self.registry = {}     def save_subscription(self, user_id, sub):        self.registry[user_id] = sub     def send(self, user_id, message, server_key):        sub = self.registry.get(user_id)        if sub is None:            raise LookupError('Subscription missing, no receiver')        ciphertext = encrypt(message, sub, server_key)        return deliver(ciphertext, sub, server_key)  def _seed(sub, server_key):    raw = server_key + sub['p256dh'] + sub['auth']    return sum(ord(c) for c in raw) & 0xFF  def encrypt(message, sub, server_key):    seed = _seed(sub, server_key)  # 密钥协商得到共享密钥    return ''.join(chr(ord(c) ^ seed) for c in message)  def deliver(ciphertext, sub, server_key):    seed = _seed(sub, server_key)    plain = ''.join(chr(ord(c) ^ seed) for c in ciphertext)    return 'delivered: %s (cipher length: %d)' % (plain, len(ciphertext))  def main():    server_key = 'vapid-server-private-key'    alice = PushClient('alice')    print('1) request permission ->', alice.ask_permission(True))    sub = alice.subscribe(        'https://push.example.com/endpoint-alice-001',        'alice-p256dh-public-key',        'alice-auth-secret',    )    svc = PushService()    svc.save_subscription('alice', sub)    print('2) subscribed ->', sub['endpoint'])    print('3) server delivers:', svc.send('alice', 'Hello Web Push!', server_key))    alice.unsubscribe()    svc.registry.pop('alice', None)    try:        svc.send('alice', 'Nobody home', server_key)    except LookupError as exc:        print('4) after unsubscribe ->', exc)  if __name__ == '__main__':    main()

1. if self.permission != 'granted':权限是订阅的前置条件，就像先拿到开门许可才能登记地址；权限不足直接抛错。
2. self.subscription = {记录订阅三件套：endpoint 是收信地址，p256dh 是加密公钥，auth 是认证密文。
3. svc.save_subscription('alice', sub)服务端持久化订阅，把新地址抄进通讯录，否则推送时找不到人。
4. sub = self.registry.get(user_id)推送前先查订阅表，查无此号直接退信。
5. raise LookupError('Subscription missing, no receiver')没有订阅还硬发消息，就像往空屋寄信，白费力气。
6. return sum(ord(c) for c in raw) & 0xFF模拟从双方密钥派生共享会话密钥（真实实现用 ECDH + HKDF）。
7. return ''.join(chr(ord(c) ^ seed) for c in message)模拟对称加密：用共享密钥逐字符异或生成密文。
8. plain = ''.join(chr(ord(c) ^ seed) for c in ciphertext)模拟接收端用同一密钥解密还原消息。
9. svc.registry.pop('alice', None)服务端同步删除订阅记录，防止继续向废弃地址投递。

常见误区

面试题