Firebase authentication提供商从password静默变更为google.com的问题咨询

你遇到的并非开启「One account per email address」后的正常官方表现，异常未触发、原有账号Provider被直接覆盖、密码登录失效都是不符合预期的异常问题。

官方启用单邮箱单账号后的预期逻辑 #

「One account per email address」开启后的标准交互流程：
当检测到同邮箱的已存在账号时，不管是哪种Provider发起的登录，Firebase Auth默认都会抛出auth/account-exists-with-different-credential错误，同时返回该账号已绑定的所有登录方式列表，引导用户通过原有方式验证身份后，再将新的OAuth凭证关联到原有账号，不会直接替换原有账号的Provider绑定关系。

异常行为的常见触发原因 #

• 最普遍的踩坑场景：之前用Gmail注册的邮箱密码账号没有完成邮箱验证。「One account per email address」的跨Provider冲突校验，只对已完成邮箱验证的账号生效。如果账号注册后没引导用户点击邮箱里的验证链接，这个账号在Firebase侧会被标记为低信任的未验证状态；此时用同邮箱的Google OAuth登录时，系统会认为邮箱归属权已经通过Google的身份验证流程确认，会直接把原有未验证的邮箱密码登录方式删掉，换成Google Provider，完全不会主动抛账号冲突异常，后续用户用原密码登录时自然会因为找不到对应的密码校验字段抛出auth/wrong-password。
• 第二类实现类问题：登录流程没有走官方标准封装。如果你没有用SDK内置的signInWithPopup、signInWithRedirect方法处理Google登录，而是自己拿到Google的OAuth凭证后直接调用signInWithCredential，既没有在调用前用fetchSignInMethodsForEmail提前查询该邮箱已绑定的登录方式，也没有完整捕获所有认证异常码，就会出现异常被漏处理、流程绕过内置校验的情况，看起来像是异常没触发，实际是代码逻辑跳过了官方的冲突拦截环节。

正确的处理逻辑 #

• 所有通过邮箱密码注册的账号，必须引导用户完成邮箱验证，只有验证通过的账号才能触发完整的跨Provider冲突校验
• 所有OAuth登录流程发起前，先通过fetchSignInMethodsForEmail查询目标邮箱的已绑定登录方式，如果检测到同邮箱已经存在其他Provider的绑定关系，手动引导用户完成原有身份验证后再做账号关联，不要直接执行登录覆盖操作
• 没有获得用户明确授权的前提下，不要主动移除原有账号已经绑定的登录方式

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