Amazon Cognito Google社交二次登录报email属性无法更新错误求助

以下两种方案均可在不影响现有生产用户的前提下解决该问题：

方案1：调整属性映射+Lambda触发器适配（成本最低，立即可用） #

• 首先进入Cognito用户池的身份提供商配置页，删除Google身份提供商中Google email 字段到Cognito标准email属性的映射，从根源避免Cognito每次社交登录时尝试更新不可变的email字段。
• 新建一个Cognito自定义属性例如custom:google_email，将Google返回的email字段映射到该自定义属性，自定义属性可直接设置为可变，不会触发限制。
• 配置Cognito「预注册（Pre sign-up）」Lambda触发器，仅在用户首次通过Google注册账号时，将custom:google_email的取值写入标准email属性，同时将email_verified设为true（Google返回的邮箱均已完成校验，无需二次验证），首次注册时不存在属性更新冲突，可正常写入。
• 可选补充：可在触发器中增加账号关联逻辑，若预注册时发现该邮箱已存在于用户池，直接将Google身份标识绑定到已有账号，避免同一个邮箱生成两个独立账号。

方案2：渐进式迁移到新用户池（适合长期迭代需求） #

如果后续还要接入更多社交登录能力，或不想长期维护自定义属性适配逻辑，可采用无感知用户迁移方案：

• 新建一个Cognito用户池，创建时将email标准属性设置为可变（创建属性配置阶段勾选Mutable选项即可），其余配置和旧用户池保持完全一致，配置好Google社交登录能力。
• 给新用户池配置「用户迁移（User migration）」Lambda触发器：当用户在新用户池发起登录请求时，如果新池无该用户记录，触发器自动调用旧用户池的用户验证接口校验凭证，校验通过后自动将用户的所有属性、密码哈希同步到新用户池，全程用户无感知。
• 前端逐步切换到新用户池的认证配置，通常2-4周后绝大多数活跃用户都会自动完成迁移，剩余低活跃用户可后续通过引导登录或者批量导出导入的方式完成迁移，最终下线旧用户池即可。

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