Android Firestore对Map字段使用多Where条件查询获取关注用户帖子

问题原因 #

你之前的查询逻辑和需求不匹配：

• 多个whereEqualTo条件叠加默认是AND逻辑，只会返回同时满足所有createdBy.xxx = true的帖子，仅同时属于所有你传入的作者ID的帖子才会被命中，单个作者发布的普通帖子自然无法查询到
• 直接传入HashMap匹配整个createdBy字段的方式，要求文档的createdBy结构和你传入的Map完全一致，多一个、少一个字段都无法匹配，完全不适用你的需求
  此外Firestore原生提供的Filter.or构造OR查询的能力最多仅支持10个条件，还是无法覆盖关注人数超过10的场景。

推荐解决方案 #

方案1：Feed扇出（Fan-out，最适合社交类产品的标准方案） #

这是Firestore生态下做社交Feed流的最优解，完全不受关注人数限制，查询性能极高。

数据结构设计

1. 保留原有帖子集合postCollection，结构简化为每个帖子存储authorId（发布者ID）、内容、发布时间等常规字段即可，不需要createdBy Map字段
2. 新增feed根集合，每个用户对应一个子集合，路径为feed/{当前用户ID}/posts，里面存储该用户关注的所有人发布的帖子（可以存完整帖子内容，也可以存仅用于Feed展示的精简字段+帖子ID跳转源文档）

逻辑实现

• 编写Firebase云函数，监听postCollection的新增事件：当有用户发布新帖子时，遍历该发布者的所有粉丝ID列表，批量将新帖子写入每一个粉丝的feed/{粉丝ID}/posts子集合中
• 用户取关账号时，异步删除该用户Feed集合里对应账号发布的所有帖子；用户删除帖子时，异步删除所有粉丝Feed里的对应帖子

查询代码

val currentUid = Firebase.auth.currentUser?.uid ?: return
fs.collection("feed").document(currentUid).collection("posts")
    .orderBy("createTime", Query.Direction.DESCENDING)
    .limit(20) // 按需调整分页数量
    .get()
    .addOnSuccessListener {
        val feedList = it.toObjects(PostBO::class.java)
        // 直接渲染即可
    }

优缺点

• 优点：查询性能极高，不受关注人数限制，分页逻辑简单，适合中大体量的社交产品
• 缺点：写操作放大，比如10万粉的博主发帖子需要写入10万条Feed记录，可通过Firebase批量写、云函数队列优化实现，中小体量产品完全无压力

方案2：关注列表分组查询（适合关注人数较少的场景） #

如果你不想额外维护云函数和Feed集合，且用户平均关注人数不超过几百，可以选择将关注列表分组，并行查询后合并结果。

数据结构设计

保留原有postCollection，给每个帖子新增authorId字段存储发布者ID，不需要createdBy Map字段；当前用户的关注列表存在用户文档的following数组字段中。

查询代码

val currentUid = Firebase.auth.currentUser?.uid ?: return
// 先拿到当前用户的关注列表
fs.collection("users").document(currentUid).get()
    .addOnSuccessListener { userDoc ->
        val followingList = userDoc.get("following") as? List<String> ?: return@addOnSuccessListener
        val queryTasks = mutableListOf<Task<QuerySnapshot>>()
        // 按10个一组拆分，匹配whereIn的最大限制
        followingList.chunked(10).forEach { group ->
            val query = fs.collection("postCollection")
                .whereIn("authorId", group)
                .orderBy("createTime", Query.Direction.DESCENDING)
                .limit(20)
            queryTasks.add(query.get())
        }
        // 等待所有查询完成
        Tasks.whenAllSuccess<QuerySnapshot>(queryTasks).addOnSuccessListener { results ->
            val allPosts = mutableListOf<PostBO>()
            results.forEach { snapshot ->
                allPosts.addAll(snapshot.toObjects(PostBO::class.java))
            }
            // 客户端统一按发布时间倒序排序
            allPosts.sortByDescending { it.createTime }
            // 渲染结果
        }
    }

优缺点

• 优点：不需要额外维护Feed集合和云函数，逻辑简单
• 缺点：关注人数过多时会产生大量并行查询，性能下降，客户端合并排序逻辑复杂，仅适合小体量产品

内容的提问来源于stack exchange，提问作者Zar E Ahmer