先把 Google ID token 的 sub 用作稳定用户标识，把邮箱当作可能变化的资料字段；再分别测试授权仍有效、撤销授权后重新登录，以及你产品自己的找回邮件。只有改动测试数据里的邮箱字段，不足以证明 Google 真的返回了新的身份信息。
这篇适合维护 Google 登录账号关联的开发者、QA 和账号系统负责人。
如果你负责发布验收，重点看身份连续性、重复账号风险，以及找回邮件实际到达后的账号状态。
最后更新于 2026 年 10 月 25 日；功能范围与身份字段核实自 Google Developers Blog、Google OpenID Connect 文档及 Google Account 帮助页面。 Google 开发者文章说明，美国用户自 2026 年 3 月 31 日起可使用用户名更改功能；不过，是否能操作还受账号资格影响，应以测试账号实际显示的选项和官方帮助页面为准。(developers.googleblog.com)
身份主键：sub 稳定，邮箱可变
开发者应当用 Google 邮箱还是 sub 关联用户？ 用 sub 识别 Google 身份；邮箱用于联系、展示和通知，不要把它当作永不变化的账号主键。Google 的 OIDC 文档说明，sub 对 Google 账号唯一且不会重新分配，邮箱则可能变化；sub 的最大长度为 255 个区分大小写的 ASCII 字符。(developers.google.com)
对照你的数据模型与登录查询，重点找这几类隐患：
- 用户表把邮箱设为唯一主键，或把邮箱作为 Google 用户的唯一查找条件。
- 外部身份关联表没有保存提供方与
sub，登录时只能靠邮箱猜测账号归属。 - 收到新邮箱后，系统直接创建新用户，或把邮箱相同的现有账号自动合并。
- 更新联系邮箱时没有验证新地址，也没有留下原值、更新时间和操作记录。
在数据库中，建议把 Google 身份单独映射到产品内部用户 ID：身份键由登录提供方和 sub 组成，邮箱放在可更新的资料字段中。邮箱相同不等于身份相同；邮箱变化也不应自动生成新身份。Google 的后端验签说明同样建议用 sub 查找用户，并提醒邮箱可能被用户更改。(developers.google.com)
登录连续性：沿用授权与重新授权分开验
Google Account 用户名变更后，Sign in with Google 返回的邮箱不应只靠界面猜测。Google 开发者说明指出：既有 OAuth 授权仍有效时，应用可能继续收到旧邮箱；用户撤销授权后再登录，则可能收到新邮箱。因此，测试结果要记录实际 token 声明与最终进入的产品账号，不能只截图登录按钮或个人资料页。(developers.googleblog.com)
撤销授权后重新登录，怎样确认没有重复创建账号？ 先保存原账号对应的内部用户 ID 与 Google sub，再撤销测试账号对自家应用的授权，之后重新执行真实登录。检查新登录记录是否仍通过相同 sub 找到原用户；同时确认邮箱字段是否按预期更新，不能因为邮箱改变就创建第二个产品账号。若授权未撤销，单独记录这一轮结果，不要把它与撤销后的结果混为一谈。
如果没有符合资格、且你获授权使用的真实测试账号，可用受控夹具覆盖自家账号关联逻辑：模拟同一 sub 对应不同邮箱、缺少邮箱、邮箱变更等输入，验证查找和更新规则。但夹具里的字段是你构造的，不代表 Google 实际签发过这些声明。
测试夹具只能回答“自家代码收到这组输入后会怎样”，不能证明 Google 登录时会返回什么。生产路径的令牌签名和声明验证，不能为了通过测试而跳过或伪造。
找回路径：登录身份不等于联系邮箱
账号找回邮件发到旧邮箱还能收到吗？ 如果指用户更改前的 Google Account Gmail 地址，Google 帮助页面说明旧地址会保留为关联地址，发往旧、新地址的邮件会进入同一收件箱。但这只能说明 Google 邮箱收件关系，不能证明你产品数据库中的联系邮箱已经更新，也不能证明你产品的恢复邮件已经成功发送。(support.google.com)
将以下三种信息分开检查：
- Google 登录身份：验签后的 ID token 中的
sub，用于识别 Google 用户。 - 产品联系邮箱：用户在你产品资料中登记、用于通知或联系的地址。
- 找回邮件目标地址：恢复流程根据账号归属与当前策略实际选出的收件地址。
对于密码重置或账号恢复，先确认邮件目标地址与预期一致，再检查收件、链接指向的环境、令牌过期与使用规则，以及完成恢复后登录的是哪个内部用户 ID。不要因为旧邮箱在 Google 收件箱里仍可收信，就跳过你产品对账号归属的验证。Google 的排障文档也提示，关联应用可能无法识别新邮箱，恢复流程通常由该应用自身处理。(support.google.com)
若测试邮件未到，先记下目标地址、触发时间、业务事件 ID 和发送服务消息 ID，再沿应用日志、发送队列、邮件服务与收件端逐层排查。可参照这份测试邮件收件与回归检查清单，不要连续重发后仅凭某一封邮件到达就判定整个找回流程通过。
发布验收：把证据分层
一次可靠的验收至少要区分三类证据：
- 夹具通过：证明你产品的账号查询、邮箱更新与重复账号防护符合预期；不证明真实 Google 登录行为。
- 真实登录通过：证明本轮特定测试账号、授权状态和环境下的 Google 登录结果；不代表所有用户、地区或账号资格都已覆盖。
- 恢复邮件实际收件：证明这次自家产品发出的邮件到达了所测收件端；不证明 Google 身份声明有效，也不证明账号关联正确。
Google 要求验证 ID token 的签名，并检查 iss、aud 和 exp 等声明；若你的环境限制 Workspace 或 Cloud 组织账号，还要按需求校验 hd。在正式登录路径执行这些检查，不能用解码出来的 JSON、手工改写的邮箱或夹具结果代替。(developers.google.com)
上线前可按这份清单逐项留证：
- [ ] 用户表的稳定关联依据是已验签 token 中的
sub，不是邮箱。 - [ ] 旧邮箱与新邮箱分别作为可更新资料测试；记录邮箱字段变化和内部用户 ID。
- [ ] 授权仍有效与撤销后重新登录分别执行，记录授权状态、返回邮箱和命中的账号。
- [ ] 重登录后没有意外创建重复账号、把数据挂到错误用户，或自动合并不同身份。
- [ ] 找回流程验证目标地址、邮件到达、链接环境、恢复结果与最终账号归属。
- [ ] 真实令牌验证没有被夹具绕过；无法进行真实用户名变更时，将其标为未验证限制。
- [ ] 验收记录注明测试环境、账号资格、时间、事件 ID、日志证据和结论适用范围。
需要处理测试邮件中的个人信息时，使用合成账号和非生产环境；不要把真实用户资料、密码或敏感内容放进临时测试收件箱。你也可以先读测试邮件数据与隐私边界说明，再决定哪些邮件内容适合用于验证。
受控收件：只证明邮件有没有到
如果还要确认自家产品的恢复邮件是否实际送达，可把测试收件箱作为收件端之一，并记录触发时间、目标地址、消息标识与实际收到的内容。这只能补足邮件收件证据，不能替代 Google 登录验证，也不能证明 sub 与产品账号关联正确。
若你只是临时测试注册、恢复流程或收一次验证码，可以用 MSGTMP 的测试收件入口隔离测试邮件，避免把测试地址交给主邮箱。银行、支付、政务等需要长期找回的重要账号，或需要持续收信、回复邮件的账户，仍应使用你能长期控制的邮箱，而不是临时收件地址。