Android Quote App中Firebase Firestore模糊查询实现方法求助

哈哈，这个问题我之前做Android项目的时候也碰到过！Firestore确实没有直接提供像SQL里WHERE CustomerName LIKE %or%这种任意位置的模糊查询，但有几种可行的方案，我给你捋一捋：

方案1：前缀/后缀匹配（官方原生支持） #

如果你的需求可以放宽到前缀匹配（比如找所有以"or"开头的CustomerName）或者后缀匹配，Firestore的startAt()和endAt()方法可以直接实现。

前缀匹配示例（Kotlin）： #

val queryText = "or"
db.collection("customers")
    .orderBy("customerName")
    .startAt(queryText)
    .endAt(queryText + "\uf8ff") // \uf8ff是Unicode中很高的字符，能匹配所有以queryText开头的字符串
    .get()
    .addOnSuccessListener { documents ->
        // 处理查询到的结果
    }

后缀匹配的额外处理： #

因为Firestore不支持直接按后缀排序，你可以在存储时额外存一个反转后的字段，比如customerNameReverse，然后对这个字段做前缀匹配：

// 存储时
val customerName = "Orwell"
val customerNameReverse = customerName.reversed() // 变成"llewrO"
db.collection("customers")
    .document("docId")
    .set(mapOf(
        "customerName" to customerName,
        "customerNameReverse" to customerNameReverse
    ))

// 查询后缀为"ll"的文档
val queryTextReverse = "ll".reversed() // 变成"ll"
db.collection("customers")
    .orderBy("customerNameReverse")
    .startAt(queryTextReverse)
    .endAt(queryTextReverse + "\uf8ff")
    .get()

这个方案的优点是不需要额外的存储开销，完全原生支持，但缺点是只能处理前缀/后缀，无法实现任意位置的匹配。

方案2：预存搜索索引字段（实现任意位置匹配） #

这是实现任意位置模糊匹配最常用的方案，核心思路是在存储文档时，把目标字段的所有可能子字符串提取出来，存到一个数组字段里，然后用Firestore的whereArrayContains()方法查询。

步骤1：存储时生成索引字段 #

比如我们要对customerName做任意位置匹配，存储时生成一个searchKeywords数组，包含该字段所有长度≥2的子串（你可以根据需求调整长度，比如只存≥2的子串减少存储量）：

Kotlin示例：

val customerName = "George Orwell"
val lowerCaseName = customerName.lowercase() // 统一转小写，避免大小写敏感
val searchKeywords = mutableListOf<String>()

// 生成所有可能的子串
for (i in 0 until lowerCaseName.length) {
    for (j in i + 1..lowerCaseName.length) {
        val substring = lowerCaseName.substring(i, j)
        if (substring.length >= 2) { // 过滤短子串，减少数据量
            searchKeywords.add(substring)
        }
    }
}

// 存入Firestore
db.collection("customers")
    .document("your-doc-id")
    .set(mapOf(
        "customerName" to customerName,
        "searchKeywords" to searchKeywords
    ))

Java示例：

String customerName = "George Orwell";
String lowerCaseName = customerName.toLowerCase();
List<String> searchKeywords = new ArrayList<>();

for (int i = 0; i < lowerCaseName.length(); i++) {
    for (int j = i + 1; j <= lowerCaseName.length(); j++) {
        String substring = lowerCaseName.substring(i, j);
        if (substring.length() >= 2) {
            searchKeywords.add(substring);
        }
    }
}

db.collection("customers")
        .document("your-doc-id")
        .set(new HashMap<String, Object>() {{
            put("customerName", customerName);
            put("searchKeywords", searchKeywords);
        }});

步骤2：查询任意位置包含目标内容的文档 #

查询时，把搜索关键词转成小写，然后用whereArrayContains()匹配：

Kotlin示例：

val targetText = "or".lowercase()
db.collection("customers")
    .whereArrayContains("searchKeywords", targetText)
    .get()
    .addOnSuccessListener { documents ->
        for (doc in documents) {
            // 处理每个匹配的文档
            val name = doc.getString("customerName")
            Log.d("Firestore", "匹配到：$name")
        }
    }

Java示例：

String targetText = "or".toLowerCase();
db.collection("customers")
        .whereArrayContains("searchKeywords", targetText)
        .get()
        .addOnSuccessListener(queryDocumentSnapshots -> {
            for (QueryDocumentSnapshot doc : queryDocumentSnapshots) {
                String name = doc.getString("customerName");
                Log.d("Firestore", "匹配到：" + name);
            }
        });

这个方案的优缺点： #

• 优点：完全实现任意位置的模糊匹配，查询效率高，是Firestore生态内的解决方案。
• 缺点：会增加文档的存储大小（尤其是长字符串），写数据时需要额外的处理逻辑。适合数据量不是特别大的场景。

方案3：集成第三方搜索服务（适合复杂搜索需求） #

如果你的App需要更强大的搜索功能（比如同义词搜索、拼音搜索、排序评分等），可以集成Firebase官方推荐的Algolia搜索服务。Firebase有专门的扩展可以一键将Firestore数据同步到Algolia，然后用Algolia的SDK实现复杂的模糊查询。

不过这个方案需要额外的服务费用，适合对搜索体验要求高的项目。

方案4：客户端本地过滤（不推荐） #

还有一种极端情况：如果你的数据集非常小（比如只有几百条文档），可以先把所有文档拉到客户端，然后在本地用字符串匹配过滤。

比如Kotlin中：

db.collection("customers")
    .get()
    .addOnSuccessListener { documents ->
        val targetText = "or"
        val matchedDocs = documents.filter { doc ->
            doc.getString("customerName")?.lowercase()?.contains(targetText) == true
        }
        // 处理匹配结果
    }

但这个方案非常不推荐，因为会消耗大量带宽和客户端资源，数据量一大就会卡顿，完全不符合Firestore的设计理念。

总结一下：

• 只需要前缀/后缀匹配：用方案1；
• 需要任意位置匹配且数据量不大：用方案2；
• 需要复杂搜索功能：用方案3；
• 数据量极小且无所谓性能：才考虑方案4。

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