Firestore实现关注项目动态流：排序与分页方案咨询

我正在构建一个用户可关注项目的动态流，需要将用户关注的项目按lastUpdated字段排序并支持分页，但暂未找到最优实现方案。

现有Firestore数据结构 #

users (collection)
  projects (subcollection)
    lastUpdated (timestamp)
  followingProjects (array of project Document IDs)

尝试过的方案（存在限制） #

曾考虑使用in操作符实现查询，代码如下：

let followingProjects = user.followingProjects
firestore().collectionGroup("projects")
           .whereField(FieldPath.documentID(), in: followingProjects)
           .order(by: "lastUpdated", descending: true)
           .limit(to: 20)
           // 后续分页逻辑：
           .start(afterDocument: startAfter)

但in操作符最多支持30个值，无法满足用户关注超过30个项目的需求。

备选方案（效率问题） #

考虑将followingProjects改为子集合，新结构如下：

users (collection)
  projects (subcollection)
    lastUpdated (timestamp)
  followingProjects (subcollection)
    id (string)
    lastUpdated (timestamp)

此方案需先查询followingProjects子集合获取最新数据排序分页，再逐个调用getDocument()获取项目详情，但项目更新时需同步更新所有关注用户的lastUpdated字段，效率较低。

请问是否存在更优的实现方案？

方案1：分批次查询+客户端合并排序 #

针对in操作符的30个值限制，将用户的followingProjects数组按每30个ID为一组拆分，分别发起查询，再在客户端合并所有结果并按lastUpdated排序处理分页。

实现要点： #

• 将followingProjects拆分为多个长度≤30的子数组
• 对每个子数组执行原有的in查询（保留order(by: "lastUpdated", descending: true)）
• 收集所有查询结果后，客户端统一按lastUpdated降序排序
• 分页时从排序后的结果集中截取对应页码的数据

优缺点： #

• 优点：无需修改现有数据结构，实现简单；避免多用户同步更新的开销
• 缺点：关注项目过多时查询次数增加；客户端合并排序会占用一定内存，需控制结果集大小

方案2：反向维护关注关系+批量更新 #

调整数据结构，在projects集合中新增followers关联，同时在用户的followingProjects中存储项目ID和对应更新时间，项目更新时通过Cloud Functions批量同步用户侧的时间字段。

优化后数据结构示例： #

projects (collection)
  lastUpdated (timestamp)
  followers (subcollection)
    userId (string)
users (collection)
  followingProjects (array of objects: { projectId: string, lastUpdated: timestamp })

实现要点： #

• 项目更新时，通过Cloud Functions遍历followers子集合，批量更新对应用户followingProjects数组中该项目的lastUpdated值
• 查询动态流时，直接从用户的followingProjects按lastUpdated排序分页，再用getAll()批量获取项目详情（一次最多50个文档）

优缺点： #

• 优点：查询效率高，分页逻辑简单；批量更新在后台执行，不影响前端体验
• 缺点：需维护双向关联关系，数据结构复杂度提升；项目更新存在一定延迟，需接受最终一致性

方案3：复合索引+分段查询优化 #

给projects集合创建lastUpdated降序+documentID的复合索引，结合用户关注列表分段查询，客户端过滤合并结果。

实现要点： #

• 按lastUpdated降序查询项目，每次用whereField("documentID", in: ...)分批次过滤用户关注的项目
• 每次查询获取超过分页所需数量的结果，直到凑够20条有效数据
• 客户端对结果去重后排序

优缺点： #

• 优点：利用Firestore索引优化查询性能；无需修改数据结构
• 缺点：若用户关注的项目在最新更新队列中占比低，可能需要多次查询才能凑够分页数据

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