Firebase Firestore实现不区分大小写搜索需额外存小写字段吗？

核心结论 #

• Firestore 原生查询没有办法完全不额外存储规范化字段，就实现稳定可靠的不区分大小写匹配。
• 原生字符串查询的匹配规则是严格逐Unicode码点比对的，"Dan"和"dan"在查询引擎看来是两个完全独立的字符串值，没有内置的忽略大小写匹配逻辑。如果直接用原字段做等值查询，只要输入内容的大小写和存储值有差异，就无法命中目标结果。

为什么必须存储独立的规范化辅助字段 #

要实现可稳定落地的不区分大小写搜索，目前经过验证的通用方案，就是在写入文档时同步存储对应字段的规范化版本作为独立辅助字段：

• 基于原始字段的原生查询（仅能匹配完全大小写、格式一致的内容）：
  db.collection("users").where("name", "==", "Dan")
• 基于规范化辅助字段的查询（可覆盖大小写差异的匹配场景）：
  写入用户文档时，提前把姓名字段统一转成全小写，存入独立的name_lowercase辅助字段；查询时把用户输入的搜索词同样做小写转换，再针对该辅助字段发起查询即可：
  db.collection("users").where("name_lowercase", "==", "dan")

这种单独存储规范化字段的模式，不只是适配不区分大小写的搜索需求，也能支撑其他类型的规范化查询场景——比如去除字符串首尾多余空格、统一特殊字符格式、标准化手机号/邮箱格式做精准匹配等，核心逻辑都是提前对存储值和查询值执行完全一致的标准化处理，才能在原生查询引擎下稳定命中结果。

各类“无需额外字段”方案的实际局限性 #

社区里零散提到的绕开额外字段的技巧，都不具备生产环境的可用性：

• 网传的范围查询技巧（比如查询区间从目标字符串到对应的Unicode最大代理项），本质是按ASCII码点的固定范围做匹配，根本覆盖不了大小写差异的字符区间（大写字母和小写字母的Unicode码点存在固定偏移，并不在同一个连续ASCII范围内），既实现不了精准的等值不区分大小写匹配，还会出现大量漏匹配、错匹配的问题，完全不能作为可靠方案使用。
• 借助云端触发器在文档写入时自动生成规范化字段的方案，本质上还是要在文档中存储规范化后的字段值，只是省去了前端写入时手动做格式处理的步骤，并不是真的不需要存储额外的规范化字段。

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