Google Conversational Action中verificationStatus、accountLinkingStatus、UserStorage及弃用用户ID的管理问题咨询

我之前开发Google Conversational Action时也踩过这俩状态的坑，来给你梳理清楚核心问题，帮你理清逻辑：

一、先搞懂两个状态的本质和可能的组合 #

首先得把这两个状态的作用掰明白，它们是完全独立的两个维度，不存在互斥关系：

• verificationStatus：看的是用户的Google账号本身是否完成了官方验证（比如绑过手机号、邮箱，通过了Google的身份校验，不是那种随便注册没验证的账号）
• accountLinkingStatus：指的是用户有没有通过OAuth流程，把你的第三方服务账号和他的Google账号关联起来

四种可能的状态组合（重点看第三点） #

1. 未验证 + 未链接：典型的新用户或者匿名访问场景，用户没登录/没验证Google账号，也没关联你的服务
2. 已验证 + 未链接：用户有合法的Google账号，但还没授权关联你的服务，这种情况很常见
3. 未验证 + 已链接：这种场景几乎不可能发生！因为OAuth账号链接的前提是用户必须登录一个已验证的Google账号——Google根本不会允许未验证的账号发起OAuth授权请求，所以这个组合你完全不用考虑
4. 已验证 + 已链接：这就是你要的目标场景，用户既有合法的Google账号，又完成了和你服务的账号关联

二、User ID弃用后的用户识别方案 #

既然官方弃用了原有的user ID，你可以换这两种更可靠的方式来标识用户：

• 账号链接后的第三方用户ID：用户完成OAuth链接后，你可以从返回的令牌里解析出你的服务系统里的用户ID，这个ID是稳定唯一的，完全可以用来做用户的核心身份标识
• UserStorage的使用边界：如果需要临时存点会话数据，记住只有当verificationStatus是VERIFIED时再用——未验证用户的UserStorage标识不稳定，而且官方也不建议给这类用户存持久化数据，避免数据混乱

三、针对你的业务需求的具体建议 #

你说“仅当用户已验证且同意授权时，才在UserStorage中存储数据”，那逻辑可以这么写：

1. 每次收到请求，先同时检查verificationStatus是否为VERIFIED，以及accountLinkingStatus是否为LINKED
2. 只有两个条件都满足时，才往UserStorage里写数据；如果有一个不满足，要么提示用户完成验证/账号链接，要么直接拒绝存储操作
3. 对于已链接账号的用户，优先用你服务侧的用户ID来做身份识别，UserStorage只用来存临时的会话数据就行，别把它当主要的用户标识来用

最后再划个重点 #

• 不用纠结两个状态的互斥问题，它们是独立的，但未验证+已链接的场景可以直接忽略
• 弃用原user ID后，账号链接后的第三方ID是最可靠的用户标识
• 严格按照“已验证+已链接”的条件来控制UserStorage的写入，就能避免大部分身份识别的问题

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