mongodb文本字段不能直接建全文索引实现真正模糊搜索，因其$text索引仅支持词干/完整词匹配，不支持前缀、中缀、后缀；需用应用层预处理构建keywords数组并建{keywords:1}索引，查询用$in而非$regex。
为什么不能直接对文本字段建全文索引做模糊搜索？
因为 MongoDB 的 $text 索引只支持“词干匹配”和“完整词匹配”，不支持前缀、中缀、后缀这类真正意义上的模糊搜索（比如搜 "elast" 匹配 "elastic"）。更麻烦的是，它默认忽略停用词、强制小写、且无法控制分词逻辑——你根本没法让它把 "user_id_123" 拆成 ["user", "id", "123"] 或保留下划线片段。
存关键字数组的实操要点：什么时候该切、怎么切、切到哪一级？
核心原则是：**由业务决定切分粒度，不是越细越好，也不是越粗越省事**。比如地址字段，存 ["北京市", "朝阳区", "建国路8号"] 比存 ["北京", "市", "朝", "阳区", "建国", "路", "8", "号"] 更有用；而日志里的错误码 "ERR_CONN_TIMEOUT_408"，则适合按 _ 拆成 ["ERR", "CONN", "TIMEOUT", "408"]。
- 用应用层预处理，别依赖 MongoDB 的聚合管道做实时切分（性能差、难调试）
- 中文优先用成熟分词库（如 jieba），别用正则
/./g暴力拆字 - 数字和字母混排字段（如
"v2.3.1-beta"）建议用[\W_]+切，保留版本号语义 - 避免存空字符串或纯空白符进数组，否则
$in查询会意外命中
keywords 数组字段怎么查才快？
必须给 keywords 字段建普通索引，类型是单字段升序索引：db.collection.createIndex({ keywords: 1 })。这不是可选项——没有这个索引，{ keywords: { $in: ["timeout", "408"] } } 就是全表扫。
- 查询时用
$in，不是$regex：前者走索引，后者永远全表扫描 - 如果要“同时包含多个关键词”，用
$all，但注意它不保证顺序，也不支持权重 - 别在
keywords上用$elemMatch套复杂条件，那会退化成集合扫描 - 数组长度超过 500 项时，写入和索引开销明显上升，得考虑是否过度切分
容易被当成“模糊搜索”但其实不是的坑
很多人以为存了关键字数组 + $in 就等于模糊搜索，结果发现搜 "admin" 找不到 "administrator"。这是因为数组里没存这个词干变体——$in 是完全匹配，不是相似匹配。
- 想支持词干扩展（如
"running"→"run"），得在写入前调用 stemmer，把原词转成词根再存进数组 - 拼音搜索（搜
"zhangsan"匹配"张三"）必须额外存一个pinyin_keywords数组，不能指望主数组覆盖 - 大小写敏感问题：MongoDB 默认区分大小写，
"Error"和"error"是两个不同关键词，统一转小写再存最省心
关键字数组模式本质是“用空间换确定性”，它快、可控、可预测，但不会自动帮你猜用户意图。真要模糊，得在它之上叠一层拼写纠错或向量相似度，而不是指望数组自己长出模糊能力。
