Web Push同一订阅者对应不同Endpoint问题及相关解决方案咨询

嘿，我来帮你拆解这个Web Push订阅统计的问题，结合实际开发实践和FCM的特性给你可行的方案：

核心问题是在无用户登录标识、无Cookie的情况下，关联同一访客的多个推送订阅Endpoint，这里有两个靠谱的思路：

1. 模糊设备特征哈希（折中方案） #

你可以收集一些非个人可识别的设备/浏览器特征，组合后生成一个模糊标识：

• 浏览器用户代理字符串（navigator.userAgent）
• 屏幕分辨率（window.screen.width + window.screen.height）
• 浏览器语言设置（navigator.language）
• 时区偏移（new Date().getTimezoneOffset()）

把这些特征拼接后做SHA-256哈希处理，生成一个不可逆的模糊标识。当用户新生成订阅时，后端先通过这个哈希值查找是否有旧的Endpoint，有的话直接替换。

⚠️ 注意：这个方法有局限性——如果用户更新浏览器、换设备，特征变化会被当成新用户，但对于纯访客场景，是相对可行的折中方案，而且要确保不收集任何可直接识别用户的信息，符合隐私法规。

2. 客户端本地存储UUID（更准确的方案） #

这个方法不用Cookie，依赖浏览器的本地存储：

• 在用户第一次访问时，生成一个随机UUID（比如用crypto.randomUUID()），存在Service Worker可访问的IndexedDB或者localStorage里
• 每次用户订阅（或页面加载）时，先从本地存储读取这个UUID，然后把UUID和新的Endpoint一起传到后端
• 后端用UUID作为用户标识，当同一UUID传来新的Endpoint时，直接替换旧的记录

只要用户不清除浏览器存储，这个UUID就会一直存在，能准确关联同一访客的所有订阅Endpoint，比特征哈希的可靠性高很多。

你说的没错，这个事件目前只有Firefox支持，Chromium系浏览器（Chrome、Edge等）还没实现。替代方案是主动检查订阅状态：

• 在用户每次打开页面时，调用registration.pushManager.getSubscription()获取当前的订阅对象
• 把当前订阅的Endpoint和后端存储的对比，如果不一致，就上传新的Endpoint并替换旧记录
• 如果当前没有有效订阅，就触发重新订阅流程

这个主动检查的逻辑能覆盖所有浏览器，确保后端始终存储的是用户当前有效的Endpoint。

必须能！FCM已经帮你封装好了底层的订阅管理逻辑，完美解决你的痛点：

• 自动处理Endpoint更新：当用户的订阅Endpoint因为浏览器更新、设备变化等原因改变时，FCM服务器会自动关联同一个设备的新旧Token，你不用自己写替换逻辑
• 访客用户标识：FCM会给每个浏览器实例分配一个唯一的FCM Token，这个Token在用户不清除浏览器存储的情况下是固定的，你可以直接用这个Token来统计订阅者数量，不用自己处理UUID或设备特征
• 跨浏览器兼容：不管是Firefox、Chrome、Edge还是Safari（部分版本），FCM都能统一处理订阅、推送和更新

不过要注意，用FCM的话，你需要把Web Push的逻辑迁移到FCM的SDK上，比如用firebase.messaging()来处理订阅、接收推送等。FCM在免费配额内足够大多数中小项目使用，成本几乎为零。

• 如果不想依赖第三方服务，优先选客户端UUID+本地存储的方案，配合页面加载时的主动订阅检查，能很好地管理访客的订阅Endpoint
• 如果想省掉底层的订阅管理、跨浏览器兼容等麻烦事，直接用FCM，开发效率会高很多

内容的提问来源于stack exchange，提问作者Nur Alam