Web应用：推送通知服务vs周期性服务器轮询方案选型咨询

首先明确：现在Web端已经能靠谱地集成推送通知，主流浏览器都有支持，结合你打算用的FCM来说，适配情况如下：

先提个必经前提 #

所有现代浏览器的Web推送都依赖Web Push API，FCM这类第三方服务也是基于它做的上层封装。但有两个硬要求：

• 网站必须走HTTPS（本地开发用localhost是例外）
• 用户必须主动点同意授权通知，不然没法推送

各主流浏览器的具体表现 #

Chrome/Edge（Chromium内核） #

这俩是支持最完善的，和FCM完美适配：

• 不管浏览器是前台还是后台，甚至浏览器关了（只要用户没彻底退出账号、没禁用通知），重新打开都能收到离线期间的推送
• 直接用FCM的JS SDK就能快速集成，几乎不用额外适配

Firefox #

同样完全支持Web Push API，和FCM兼容没问题：

• 推送逻辑和Chromium系差不多，后台离线推送也能正常工作
• 它有自己的推送中转服务器，但FCM会自动适配，不用你额外配置

Safari（Mac/iOS） #

这货是个特例，支持晚且有细节限制：

• Mac上的Safari从11.1版本就支持Web Push，后台推送也正常
• iOS上的Safari是16.4版本才正式放开Web Push，之前得把网站添加成PWA到主屏幕才能收推送（现在不用了，但还是建议引导用户加PWA，体验更稳定）
• iOS上如果彻底关掉Safari，推送可能延迟或者收不到，这是系统机制限制
• FCM对接Safari需要额外配置苹果的APNs证书，FCM会自动把推送请求转发给APNs，你只要在苹果开发者后台弄好证书就行

替换轮询的实打实好处 #

• 比轮询省太多资源：推送是有新消息才触发，不像轮询不管有没有消息都要发请求，用户越多、在线时间越长，省的资源越明显
• 消息实时性强，不用等轮询的间隔时间，用户能马上收到聊天通知

要踩的坑提前注意 #

• 别一进网站就弹授权请求，最好等用户第一次用聊天功能的时候再提示，不然用户大概率会拒绝，后面再想授权就麻烦了
• 要监听通知权限的变更，如果用户后来关掉了通知，得自动切回轮询方案，别让消息丢了
• 测试一定要覆盖iOS Safari的场景，这货的兼容性问题最多

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