MongoDB $text 搜索对长文本效果差，因默认词干索引、停用词过滤、不支持中文分词及短语匹配；需手动预处理（如 jieba 分词）、显式设 language 和 weights，并结合业务二次过滤。
为什么 $text 搜索对长文本“好像没效果”
因为 $text 默认只索引词干（stemmed tokens），且自动过滤停用词、忽略标点和大小写——这对短标题很友好，但长文本里关键语义常藏在上下文或修饰结构中，一剪就断。比如“用户在2024年3月误点了删除按钮”，$text 可能只留下 user、click、delete，丢了时间、动作主体和误操作这个核心判断。
- 停用词列表不可配置（如中文无内置停用词支持，英文默认过滤
the、and等） - 不支持短语匹配：
"误点删除"会被拆成两个独立词，无法保证相邻 - 索引时不保留原始位置信息，没法做 proximity 或 phrase boost
用 text 索引前必须手动预处理中文长文本
MongoDB 原生 $text 对中文基本不支持分词——它把整段中文当一个 token 处理，导致几乎搜不到任何东西。你得自己切好词，再存进字段供索引。
- 别依赖 MongoDB 自动分词：中文必须用外部工具（如
jieba、ansj或THULAC）提前分词，生成空格分隔的字符串 - 分词后建议小写归一化（避免大小写敏感干扰），但别删标点——某些场景下标点是语义锚点（如“API vs SDK”里的
vs） - 字段名要明确，比如存到
content_searchable，而不是覆盖原始content，方便调试和回滚 - 示例（Python + jieba）：
import jieba<br>text = "用户在2024年3月误点了删除按钮"<br>seg_list = jieba.cut(text)<br>doc["content_searchable"] = " ".join(seg_list) # → "用户 在 2024 年 3 月 误点 了 删除 按钮"
text 索引的权重和语言设置不是可有可无的选项
不设 language，MongoDB 默认按英文规则解析，中文字段直接被当“单个乱码词”跳过；不配 weights，标题、摘要、正文全被平权对待，结果相关性极差。
-
language必须显式指定：{ language: "none" }强制关闭词干提取（适合已预分词的中文），或{ language: "zh" }（仅当 MongoDB 版本 ≥ 4.2 且启用 ICU 支持时才有效） -
weights按字段重要性加权，比如标题比正文重要三倍：db.articles.createIndex(<br> { title: "text", content_searchable: "text" },<br> { weights: { title: 3, content_searchable: 1 } }<br>) - 权重只影响排序（
$meta: "textScore"），不影响是否命中——想控制召回，得靠查询语法
$text 查询时用错操作符，模糊就变“全匹配”
$text 默认是 OR 逻辑，但很多人误以为加引号就能精准匹配短语，其实不行。真正可控的只有三个操作符：$search、$caseSensitive、$diacriticSensitive，没有 $phrase 或 $near。
-
$search中的双引号仅表示“该词必须出现”，不是短语匹配："误点 删除"表示两个词都得存在，但可以隔开任意距离 - 想逼近短语效果？只能靠预处理时把常见短语合并为新词（如把“误点删除”作为一个分词项存入
content_searchable） - 大小写敏感默认关着，查
"API"会同时命中api和Api，真要区分就得开$caseSensitive: true，但注意这会让索引体积翻倍、查询变慢 - 错误示范：
{ $text: { $search: "用户 删除按钮" } }→ 可能返回“用户没删按钮”这种反例；正确思路是结合业务补过滤：{ $text: ..., status: "deleted" }
MongoDB 的 $text 不是 Elasticsearch，它没 query DSL、没 analyzer 链、也没 term frequency 控制。长文本模糊搜索真正可靠的路径，其实是“人工分词 + 权重设计 + 查询后二次过滤”，而不是指望一个索引解决所有问题。最容易被忽略的是：索引建完不测试分词效果，直接上线，结果线上搜不到任何东西——先用 db.collection.find({ $text: { $search: "关键词" } }).explain("executionStats") 看实际匹配了哪些 token。
