基于Firestore与布隆过滤器实现Tinder式Ionic3应用用户去重问询

嘿，我来帮你搞定这个Tinder风格应用里避免重复展示已滑用户的问题！结合你用Firestore+Ionic3的技术栈，咱们一步步来解决：

第一步：先调整用户数据结构 #

首先得给每个用户的Firestore文档加个字段，用来记录已经滑过的用户。我建议加一个swipedUsers数组，专门存当前用户已经左滑/右滑过的所有用户UID。这样每次用户完成一次滑动操作，咱们就能把对方的ID记下来，后续查询就可以排除这些人了。

第二步：修改Firestore查询，过滤掉已滑用户 #

结合你现有的兴趣匹配查询，咱们要加两个额外条件：一个是排除当前用户自己（总不能让用户滑到自己吧），另一个就是排除已经在swipedUsers里的用户。

假设你的当前用户信息存在this.currentUser里，修改后的查询代码应该是这样的：

this.firestore.col$('Users', ref => ref
  // 保留你原来的兴趣匹配逻辑，比如按兴趣交集筛选
  .where('interests', 'array-contains-any', this.currentUser.interests)
  // 先排除当前用户自己
  .where('uid', '!=', this.currentUser.uid)
  // 排除已经滑过的用户，如果swipedUsers为空就传空数组避免报错
  .where('uid', 'not-in', this.currentUser.swipedUsers || [])
);

注意not-in的小限制 #

这里要提一句：Firestore的not-in操作符最多支持50个值。如果你的用户可能滑过超过50个用户，这个方法就会失效。这时可以换个思路：

1. 给每个用户创建一个swiped子集合，每个文档的ID直接用被滑用户的UID（不用存额外数据，只要文档存在就代表滑过）
2. 之后查询时，先获取当前用户swiped子集合里的所有UID，要是数量<=50就继续用not-in；要是超过50，就分页加载用户，每次加载时排除已滑的，或者用批量查询的方式拆分。

不过一般来说，普通用户滑到50个以上的情况不算特别多，先按数组的方式来就行，真遇到再优化。

第三步：滑动完成后记得更新已滑列表 #

当用户对某个用户完成左滑/右滑后，一定要把对方的UID加到当前用户的swipedUsers数组里。这里推荐用Firestore的arrayUnion方法，它会自动避免重复添加同一个ID，就算用户不小心重复滑了同一个人，数组里也不会有重复值：

// 假设swipedUserId是被滑用户的UID
this.firestore.doc(`Users/${this.currentUser.uid}`).update({
  swipedUsers: firebase.firestore.FieldValue.arrayUnion(swipedUserId)
});

小优化：缓存已滑列表提升性能 #

可以把当前用户的swipedUsers数组在登录时缓存到本地，不用每次查询用户列表都重新从Firestore拉取，这样能减少读取次数，让应用更流畅。每次滑动更新数组后，同步更新缓存就行。

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