结论：没有“通用高效”的模糊搜索，只有“匹配场景的合理选型”——$regex适合低频、小数据量的中间/后缀匹配；文本索引（$text）适合多词、语义化、前缀主导的全文检索；真正高频或复杂模糊需求应移出MongoDB。
直接说结论：没有“通用高效”的模糊搜索，只有“匹配场景的合理选型”——$regex 适合低频、小数据量的中间/后缀匹配；文本索引（$text）适合多词、语义化、前缀主导的全文检索；真正高频或复杂模糊需求（如拼写容错、拼音、近义词），应移出 MongoDB。
什么时候该用 $regex，又为什么它常常很慢
当你需要匹配子串（比如查 "ket" 是否出现在 "cricket" 中）、或字段值格式不规整（如日志行、用户自由输入昵称），$regex 是最直接的选择。但它在绝大多数模糊场景下无法走索引：
- 只有
^prefix这种**严格前缀匹配**才可能利用 B-tree 索引，例如/^apple/；/apple/或/.+apple.+/会触发全集合扫描（COLLSCAN） - 数组字段上的
$regex（如{"hobby": {"$regex": "ket"}}）完全无法被普通索引加速，MongoDB 不支持对数组元素做正则索引 - 选项
"i"（忽略大小写）会让索引失效，除非你建的是带 collation 的索引且明确指定 locale
文本索引（$text）能解决什么，不能解决什么
$text 查询快，是因为它依赖倒排索引，但它的语义和能力边界非常明确：
- ✅ 支持多字段联合搜索（
createIndex({title: "text", content: "text"})）、词干提取、停用词过滤、权重控制 - ❌ 不支持子字符串匹配：
$text只能匹配完整词项（token），搜"ket"不会命中"cricket"；也不能用正则语法 - ❌ 不支持
$and/$or与其他非$text条件混用在同一查询中（除非用聚合管道的$match分阶段） - ⚠️ 文本索引字段必须是字符串或字符串数组；对数字、日期、嵌套对象无效
真正高频模糊搜索，别硬扛在 MongoDB 里
如果你的应用要求“输入错一个字也能找到”“支持拼音首字母”“响应必须
- 正则注入风险必须处理：用户输入的
id传给$regex前，务必用regexp.QuoteMeta(id)转义 - mgo 驱动已归档，新项目请直接用官方
mongo-go-driver，其bson.RegEx构造更清晰，也支持上下文超时控制 - 性能临界点很现实：百万级文档上跑无索引
$regex，P95 延迟很容易突破 2s；而文本索引在千万级数据下仍可维持百毫秒级 - 长期看，这类需求更适合交给 Elasticsearch、Typesense 或 PgVector（如果用 PostgreSQL），MongoDB 应专注其强项：灵活 schema、原子更新、地理空间、事务一致性
最常被忽略的一点：模糊搜索的“高效”，往往不取决于数据库怎么查，而取决于你是否提前把“可搜索项”做了结构化预处理——比如把 "cricket" 拆成 ["cri", "crick", "cricket", "icket"] 存为关键词数组，再用 $in 精确查。这比任何运行时正则都快，也更容易索引。
