Web Push从GCM迁移FCM及Lambda适配：百万订阅者迁移方案咨询

先帮你梳理下核心困境：你那运行2年、坐拥2-3百万订阅的Web Push服务，迁去AWS Lambda后，旧GCM密钥触发401错误，新建FCM密钥又因Sender ID不匹配报错——这确实是GCM转FCM过程中常见的坑，我来逐个解答你的问题：

1. 如何迁移现有GCM项目至FCM并保留原Sender ID？是否可行？ #

完全可行，而且你的GCM项目其实早就自动迁移到FCM了。Google在2019年GCM停止服务前，就把所有GCM项目无缝迁移到了Firebase平台。你不需要新建FCM项目，而是要：

• 登录Firebase控制台，找你原来GCM项目对应的条目（它会显示“已迁移的GCM项目”类似标识，如果找不到，大概率是你登录的账号不是原GCM项目的所有者）；
• 进入项目设置的「云消息传递」标签，获取旧版服务器密钥（注意不是新的V1 API密钥，pywebpush这类库通常还是依赖旧的HTTP协议，用这个密钥就行）；
• 这个迁移后的项目，Sender ID和你原来的GCM Sender ID完全一致，用它的密钥推送，就不会出现MisMatchSenderId错误。

千万别新建全新的FCM项目，那样Sender ID会变，直接和旧订阅的Sender ID不匹配——这就是你现在遇到报错的核心原因。

2. 若无法迁移，2-3百万现有订阅者该如何处理？是否会丢失订阅者？是否需要重新订阅获取新信息？ #

如果真的找不到原GCM项目（比如原账号丢失），那旧订阅确实无法用新FCM密钥推送，因为Sender ID和订阅是绑定死的。这种情况下：

• 不会全部丢失订阅者：你可以采用渐进式替换策略——当用户访问你的网站时，自动检查并更新他们的订阅信息；
• 长期不活跃用户会逐渐失效：那些很久没访问网站的用户，你无法主动更新他们的订阅，他们会收不到推送，直到下次访问时重新订阅；
• 必须重新订阅：旧的GCM订阅已经无法使用，必须用新的FCM Sender ID获取新的订阅信息才能继续推送。

3. 若需重新订阅，是否会再次触发浏览器的权限请求？ #

放心，不会触发权限弹窗。只要用户之前已经授予过通知权限，你可以在后台静默完成订阅更新：

• 当用户加载网站时，先获取现有的PushSubscription对象，检查它关联的Sender ID（或者通过endpoint判断，GCM的endpoint格式是https://android.googleapis.com/gcm/send/xxx，迁移后FCM的可能是https://fcm.googleapis.com/fcm/send/xxx，但核心是Sender ID匹配）；
• 如果发现订阅的Sender ID和新的FCM Sender ID不匹配，调用registration.pushManager.subscribe()方法，传入新FCM项目的应用服务器公钥；
• 浏览器会直接返回新的PushSubscription，不会再次弹出权限请求，你只需要把新的订阅信息替换数据库里的旧条目即可。

额外实操建议 #

• 先小范围测试：找一批测试用户，用迁移后的FCM密钥（对应原Sender ID）推送，确认没有401或MisMatchSenderId错误后再全量切换；
• 更新pywebpush版本：确保Lambda里的pywebpush是最新版，旧版本可能对FCM的兼容性不好；
• 监控推送失败：在推送逻辑里记录失败请求，对返回MisMatchSenderId或401的订阅标记为待更新，等用户下次访问时自动触发重新订阅。

内容的提问来源于stack exchange，提问作者Mahammad Adil Azeem