Firebase：使用Google登录提供商时如何处理重名displayName问题

方案1：全局唯一公开用户名生成（优先推荐） #

这个方案可以保证URL完全无额外冗余字段，也不需要额外的中间选择页：

• 用户首次通过Google账号完成授权后，先对返回的displayName做标准化预处理：去除特殊字符、空格替换为连字符/直接删除、统一转为小写，得到初始用户名候选，比如John Doe会被处理为johndoe
• 触发Firestore事务做唯一性校验：查询用户名映射集合中是否存在相同的候选名，如果不存在，直接将该候选名作为用户的唯一公开用户名写入数据库；如果已经存在n条相同前缀的记录，自动在候选名后追加n+1的后缀，比如第二个重名用户会得到johndoe2的公开用户名
• 可额外提供1-2次免费修改用户名的权限，允许用户自定义未被占用的公开名，兼顾个性化需求
• 所有用户路由直接使用该全局唯一的公开用户名拼接，最终生成的URL格式为https://myapp.com/johndoe、https://myapp.com/johndoe2，完全满足整洁性要求

方案2：隐式匹配逻辑（保留原始displayName在URL） #

如果你希望完全保留用户原始displayName的展示，不追加任何后缀，可以用路由隐式匹配逻辑：

• 用户访问https://myapp.com/JohnDoe时，后台先按标准化后的johndoe检索所有匹配的用户列表
• 如果仅匹配到1个用户，直接跳转至该用户的资料页；如果匹配到多个重名用户，展示一个重名选择列表，显示每个用户的头像、注册时间等辅助信息供访问者选择目标账号
• 登录态下的个人路由可以优先匹配当前登录用户的账号，无需走选择逻辑

Firestore存储适配建议 #

• 不要直接使用第三方登录返回的displayName作为路由索引字段，单独新增public_username字段存储全局唯一的公开用户名
• 单独建立username_index集合，以公开用户名为文档ID，对应值为用户UID，注册时先尝试写入该集合，写入成功再更新用户主文档，通过Firestore的事务原子性避免并发注册导致的重名冲突

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