Chrome下Web Push订阅过期的重订阅处理方案咨询

首先明确核心事实：Chromium系浏览器不会对外暴露Push订阅的精确有效时长，旧版Chrome长期存在pushsubscriptionchange事件不触发的问题，订阅默认24小时强制轮换是浏览器内置策略，不是业务代码配置错误。

服务端第一层兜底 #

这是所有方案里可靠性最高的环节，不要完全依赖客户端主动上报：

• 使用zaru/webpush发送推送时，只要捕获到410 Gone响应（对应报错信息push subscription has unsubscribed or expired.），立刻将数据库中对应的旧订阅标记为永久失效，后续不再对该订阅发起推送请求
• 给失效订阅绑定的用户ID打待更新标记，等对应用户下次打开站点时，触发客户端重订阅流程
• 不要硬编码“订阅1天过期”的规则，不同浏览器版本、隐私模式、网络环境下的订阅有效期可能更短，以推送时实际返回的410状态作为订阅失效的判断标准，准确率最高

客户端无依赖主动续订逻辑 #

不需要等浏览器触发事件，在用户每次访问站点时执行检查即可，逻辑可以放在页面主线程加载逻辑中，也可以放在Service Worker的activate回调里：

1. 触发检查时，首先调用registration.pushManager.getSubscription()获取当前浏览器端留存的订阅对象
2. 如果返回值为null，直接走全新订阅流程，生成新订阅后提交到服务端存储
3. 如果拿到了现存订阅，做两层校验：
   • 对比本地缓存的上次成功提交到服务端的订阅endpoint值，如果和当前拿到的endpoint不一致，说明浏览器已经自动轮换了订阅，立刻将新订阅提交到服务端
   • 读取本地存储的上次成功订阅时间戳，只要距离当前时间超过20小时（预留4小时冗余，避开24小时强制过期的时间点），不管当前订阅看起来是否有效，都先调用subscription.unsubscribe()退订旧订阅，重新生成新订阅提交到服务端
4. 提交新订阅时必须携带当前用户的唯一标识，服务端收到后直接替换该用户名下所有旧的失效订阅记录，避免积累无效数据

兼容支持pushsubscriptionchange事件的浏览器版本 #

虽然旧版Chrome不支持该事件，但还是要在Service Worker中添加监听，覆盖已经支持该特性的版本：

• 监听pushsubscriptionchange事件，事件触发时等待获取新的订阅对象，立刻通过接口上报给服务端即可
• 事件处理逻辑不要加额外操作，该事件的生命周期很短，拿到订阅后直接上报，避免被浏览器提前终止导致上报失败

注意：所有订阅/续订操作必须在用户主动打开站点、页面处于前台可见状态时执行，浏览器会拦截后台隐藏状态下发起的推送订阅请求，会导致续订失败。

zaru/webpush库适配提示 #

发送推送时合理设置消息TTL，建议最长不超过24小时，避免服务端向已经过期的推送队列积压发送请求，减少无效410请求占比。

内容的提问来源于stack exchange，提问作者Wagner Moreira