FlutterFire中Firestore whereNotIn查询分块处理的问题解析

问题背景

在使用FlutterFire的Cloud Firestore插件时，开发者经常会遇到需要排除大量文档ID的查询场景。Firestore本身对whereNotIn操作有一个限制：每次查询最多只能排除10个文档ID。为了绕过这个限制，常见的解决方案是将ID列表分块处理，然后执行多次查询。然而，这种分块处理方式在实际应用中可能会产生意外的结果。

问题现象

当开发者尝试排除超过10个产品ID时，采用分块查询的方法会出现以下问题：

1. 每个分块查询独立执行，不考虑之前分块已经排除的ID
2. 最终结果集中可能会出现重复文档
3. 某些应该被排除的文档可能仍然出现在结果中

技术分析

问题的核心在于Firestore查询的执行机制。每个分块查询都是独立的，它们之间不会自动共享排除条件。举例来说：

假设有16个产品ID需要排除，分成两个分块：

• 第一个分块排除ID 1-10
• 第二个分块排除ID 11-16

第一个查询会返回不包含1-10的文档，第二个查询会返回不包含11-16的文档。但是这两个查询的结果合并时，那些既不在1-10也不在11-16的文档会被两个查询都返回，导致结果集中出现重复。

解决方案

经过技术验证，我们推荐以下解决方案：

1. 执行分块查询：仍然将ID列表分成不超过10个一组的分块
2. 合并结果并统计出现次数：记录每个文档在结果集中出现的次数
3. 筛选最终结果：只保留出现次数等于分块数的文档

这种方法的原理是：真正应该被包含的文档会在每个分块查询中都出现（因为它们不在任何排除分块中），而那些应该被部分排除的文档则不会出现在所有分块查询的结果中。

实现代码示例

// 执行分块查询
for (final chunk in chunks) {
  final querySnapshot = await firestore
      .collection('products')
      .where(FieldPath.documentId, whereNotIn: chunk)
      .get();
  
  result.addAll(querySnapshot.docs.map((doc) => ProductModel.fromJson(doc.data())));
}

// 统计文档出现次数
var resultMap = Map();
result.forEach((element) {
  if(!resultMap.containsKey(element.productId)) {
    resultMap[element.productId] = 1;
  } else {
    resultMap[element.productId] += 1;
  }
});

// 筛选最终结果
List<ProductModel> finalResults = [];
resultMap.forEach((k,v) {
  if(v == chunks.length){  // 只在所有分块查询中都出现的文档才是真正有效的
    for(var item in result){
      if(item.productId == k){
        finalResults.add(item);
        break;
      }
    }
  }
});

return finalResults;

最佳实践建议

1. 考虑性能影响：这种方法需要执行多次查询，可能会影响性能，建议在必要时使用
2. 限制排除ID数量：尽量避免需要排除大量ID的场景，考虑重构数据模型
3. 缓存结果：对于频繁使用的查询结果，考虑实现缓存机制
4. 监控查询成本：注意这种方法会增加Firestore的读取次数

总结

处理Firestore中大量文档ID排除的需求时，开发者需要理解分块查询的局限性。通过统计文档出现次数并筛选的方法，可以有效解决分块查询带来的重复结果问题。这种解决方案虽然增加了代码复杂度，但保证了查询结果的准确性。在实际应用中，开发者应根据具体场景权衡查询性能和结果准确性。