MongoDB 默认大小写敏感，{name: "Alice"} 查不到 "alice"；需用 collation 创建大小写不敏感索引并查询时显式指定相同 collation 才生效。
为什么 db.collection.find({name: "Alice"}) 找不到 "alice"？
MongoDB 默认是大小写敏感的，字符串比较完全按字节值进行。哪怕文档里存的是 "alice"，用 {name: "Alice"} 查询也匹配不上——这不是 bug，是设计如此。如果你需要“用户输入不管大小写都能查到”，就得显式处理大小写逻辑，不能依赖默认行为。
用 collation 创建真正的 Case-Insensitive 索引
最稳妥、性能最好的方式是建带 collation 的索引，而不是每次查询都调 $regex 或手动转大小写。MongoDB 4.0+ 支持在索引定义中指定排序规则，让索引本身理解“a”和“A”等价。
实操建议：
- 索引必须和查询时用的
collation完全一致，否则索引不会被命中（即使存在） - 推荐用
{locale: "en", strength: 2}：strength 2 表示忽略大小写和重音，但区分字母和符号（比如 “cafe” 和 “café” 视为相同，“cafe” 和 “cafe!” 则不同） - 建索引命令示例：
db.users.createIndex({name: 1}, {collation: {locale: "en", strength: 2}}) - 后续查询必须带上同样
collation才能走这个索引：db.users.find({name: "ALICE"}).collation({locale: "en", strength: 2})
查询时漏掉 .collation() 就等于没建索引
这是最容易踩的坑：索引建了，但查询不显式声明 collation，MongoDB 会回退到默认二进制排序规则，直接绕过你精心建的 case-insensitive 索引。
常见错误现象：
-
explain()显示"stage": "COLLSCAN"（全表扫描），说明没走索引 - 用
mongostat或慢日志发现该查询响应变慢、CPU 升高 - 应用层测试看似正常，但数据量一上去就明显卡顿
解决方法只有一个：所有涉及该字段的等值查询、范围查询（如 {$gt: "a"}）、排序（.sort({name: 1})）都必须配对使用 .collation({locale: "en", strength: 2})。
别用 $regex 替代 collation 索引
有人图省事写 {name: {$regex: "^alice$", $options: "i"}}，短期能跑通，但隐患很大：
-
$regex几乎无法有效利用普通索引，更别说 case-insensitive 索引 - 正则表达式引擎开销大，尤其当字段基数高或文档量大时，容易拖垮整个分片
- 无法支持
.sort()或复合查询中的高效排序，后续扩展性差 - 如果字段有空值或 null，
$regex行为还可能和预期不一致
除非是模糊前缀搜索（如 ^ali）且数据量极小，否则不要把它当 case-insensitive 查询的常规解法。
真正要支持大小写无关，索引 + 查询双侧统一 collation 是唯一可伸缩的路径。错一个环节，整条链路就掉回低效模式。
