mongodb全文索引默认用snowball分词器，将短横线、下划线、点号等标点符号在分词时切开并丢弃，导致“user-name”仅索引为“user”和“name”；且“-”在$text中兼具标点与逻辑否定符双重身份，进一步干扰匹配。
MongoDB全文索引无法匹配部分字符（比如短横线 -、下划线 _、点号 . 等），根本原因不是“索引建错了”，而是分词器在建索引和查询两个阶段都默认把它们当标点过滤掉了——你查 "user-name"，它实际只索引了 "user" 和 "name" 两个独立 token。
为什么 - 这类符号在 $text 查询里总被忽略
MongoDB 默认用 Snowball 分词器，其规则是：所有 Unicode 标点（含 -、_、.、/）在分词时直接切开并丢弃。这不是 bug，是设计如此。更麻烦的是：- 在 $search 字符串里还有双重身份——既是标点，又是逻辑否定符（如 "apple -pie" 表示“含 apple 但不含 pie”）。所以即使你写 "user-name"，它可能被解析成“查 user，再排除 name”。
- 现象：存入
{"desc": "e-mail address"}，执行db.coll.find({$text: {$search: "e-mail"}})零结果 - 验证方式：用
db.coll.explain("executionStats").find(...)看parsedTextQuery字段，会发现terms里只有e和mail - language 设置无效：无论设
language: "none"还是"en"，标点过滤这步不会跳过
不用改分片配置，也能让 - 被当普通字符查
分片集群里改分词器要动 mongos 配置和所有 shard 的启动参数，上线风险高，且不解决单机版问题。更务实的做法是绕过分词环节，靠查询语法或数据预处理把符号“保下来”：
- 用双引号强制字面匹配：
db.coll.find({$text: {$search: "\"e-mail\""}})—— 注意是外层单引号包裹整个字符串，内部双引号需转义 - 反斜杠转义单个符号：
db.coll.find({$text: {$search: "e\-mail"}})，但仅对部分符号有效，-可行，.不行 - 写入时归一化：把
-替换成下划线或空格，如"user_name"或"user name"，再建 text 索引，查的时候也按同样规则拼 - 加字段专供搜索：新增
searchable_id字段存处理后的值（如"user_name"），对该字段单独建text索引，避免污染原始字段
$regex 能查 -，但别直接上，先看索引是否真生效
很多人一碰到 $text 失效就切 $regex，结果性能暴跌。因为 $regex 默认全表扫描，除非满足两个硬性条件：
- 正则必须以
^开头（前缀匹配），例如{id: {$regex: "^user-name"}} - 不能带
i标志（忽略大小写），否则索引失效；如需大小写不敏感，得另建小写字段（如id_lower）并索引它 - 字段上必须有对应 B-tree 索引：
db.coll.createIndex({id: 1})，通配符索引{"$**": 1}对此无用 - explain() 中看到
"stage": "IXSCAN"且"nReturned"接近"nReturned"才算真正走索引；如果"nReturned"很小但"totalKeysExamined"很大，说明索引扫了大量键却没命中几条，效率仍差
真正难处理的不是单个 -，而是混合场景：既要支持 "API-key" 精确查，又要支持 "key" 泛查，还得兼容中文分词。这时候得拆解需求——精确匹配走 $regex + 前缀索引，泛查走 $text + 预分词字段，两者共存，而不是指望一个索引解决所有问题。
