OAuth2社交登录的用户信息存储与唯一标识设计咨询

你考虑的「平台标识+平台用户ID」组合完全可行，而且是业内最常用的方案之一，先给你明确这点。下面是几种主流的实现方案，以及各自的适用场景：

一、「平台标识+平台用户ID」联合唯一约束（你的方案） #

• 具体操作：在用户表新增两个字段，比如provider（存Google/Facebook/Apple这类平台的标识，用固定字符串如"google"、"facebook"，或者枚举值）和provider_user_id（存平台返回的唯一用户ID，比如Google的sub字段），然后给这两个字段加联合唯一约束。
• 核心优势：
  • 彻底避免账户冲突：不同平台的用户ID可能撞号，但加上平台标识后，组合起来绝对唯一，不会出现重复创建账户的问题。
  • 稳定性拉满：平台返回的用户ID（比如Google的sub）是永久不变的，哪怕用户改了邮箱、昵称，这个ID都不会变，保证同一用户多次登录只会匹配到同一个账户。
• 注意事项：
  • 平台标识要统一格式，别一会儿用"google"一会儿用"Google"，建议全小写字符串或者枚举值，避免大小写导致的约束失效。
  • 存储provider_user_id时别瞎改格式，比如有些平台返回的是长数字字符串，别转成数字类型，否则可能出现精度丢失的问题。

二、主用户表独立主键+第三方身份关联表（更灵活的方案） #

• 具体操作：
  1. 主用户表用自增ID或者UUID作为唯一主键（比如user_id），只存用户的通用信息，比如昵称、头像、常用邮箱这些。
  2. 单独建一张user_oauth_identity关联表，字段包括user_id（关联主用户表的外键）、provider、provider_user_id，同样给后两个字段加联合唯一约束。
• 核心优势：
  • 支持多平台绑定：用户可以同时用Google和Facebook登录同一个账户，关联表里会存两条记录，对应同一个user_id。
  • 结构清晰，扩展性强：后续要加手机号登录、邮箱自建登录，直接在主用户表加字段或者新增其他关联表就行，不会影响现有第三方登录的逻辑。
• 适用场景：需要支持用户绑定多个社交平台，或者未来可能扩展自建登录功能的系统。

三、直接用平台用户ID做主键（不推荐） #

• 具体操作：把平台返回的用户ID直接当主用户表的主键。
• 问题所在：
  • 不同平台的用户ID可能重复，比如Google的某个用户ID和Facebook的某个用户ID刚好一样，直接就会导致账户冲突。
  • 没法支持同一用户绑定多个平台，扩展性极差。
• 仅适合只对接单一第三方平台的极简小系统。

额外细节提醒 #

• 不管用哪种方案，都可以同步存储平台返回的邮箱、昵称等信息，但绝对不能用这些作为唯一标识——用户随时能改这些信息，只有provider_user_id是平台保证永久不变的。
• 针对Apple登录要注意：Apple返回的sub字段在不同应用下是不一样的，如果你的系统有多个应用，需要把client_id也加入联合约束，或者用Apple提供的团队级用户标识（如果有需求的话）。

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