我有一个名为用户的FiRecovery集合，它存储了我所有的用户信息。注册新用户时，我首先将他们注册到Firebase Auth，然后在用户集合中创建记录。现在我将UID存储为一个字段，这意味着当我想查询用户信息时，我需要使用WHERE子句进行查询。然而，更快查询的另一种选择是将UID存储为集合的文档ID。这将使我可以使用特定的ID查询集合，直观地看起来更快。
使用UID作为文档ID让我担心一些事情：
UID的唯一性在将其用作Fi恢复集合中的文档ID时意味着唯一性。假设您只基于UID进行查询，那么使查询尽可能高效的更好方法是什么？还是差异可以忽略不计，这是一个有争议的问题？
是的，这是最推荐的方法，因为Firebase auth确保您的用户拥有唯一的id，因此无需担心重复。另一件事是存储uid以外的单独id是多余的，因为您在应用程序中大部分时间都需要用户uid，以确保auth用户和存储的用户是同一个人。
如果Firebase Auth中的uid是唯一的，并且您正在根据Firebase Auth中的uid构建用户集合，那么将填充用户集合的uid也将是唯一的。
唯一不会出现这种情况的方法是，如果您将手动生成的条目与您自己的uid混合到用户集合中，而这些uid不遵循Firebase Auth的生成过程。
今年早些时候，我做了一个类似的小项目，基本上就是这样做的（用户登录谷歌，uid被添加到用户集合中，然后他们的数据被存储在他们的uid下）。这不是一个商业产品，我的用户群相当小，但当时我没有观察到任何担心的理由。
回复：速度，我不确定影响是什么，但我希望它可以忽略不计，可以称之为无意义。查询集合基本上只是在列表/数组中搜索一个值，大多数后端倾向于非常有效地处理这样的基本操作。
我不确定我是否可以假设Firebase Auth中UID的唯一性在将其用作Fi恢复集合中的文档ID时意味着唯一性。
Fi恢复生成的文档ID是完全随机的。所以没什么好担心的。
我观看了Todd的教程视频，该视频说如果您使用Fi恢复提供的自动生成的文档ID，查询会更快。鉴于此，当已知提供的文档ID查询速度更快时，我不想冒险使用其他东西。
当只需要读取单个文档（例如用户文档）时，始终建议创建指向该文档的文档引用，而不是执行查询。查询基本上意味着它需要评估所有记录才能提供结果。
使用UID作为文档ID是一种非常普遍的做法。
