全文索引权重仅能在createindex()时设置，不可运行时修改；需删除重建索引才能变更，且仅对"text"字段生效，权重为正整数，影响$text查询的score排序而非匹配逻辑。
全文索引权重只能在 createIndex() 时设置
权重不是运行时可调参数，也不是通过 updateIndex() 或类似命令修改的。一旦索引创建完成，weights 就固化在索引定义中。想改权重？必须删掉旧索引、重建新索引——这会触发全量重建，对大集合可能阻塞读写数分钟甚至更久。
常见错误现象：db.collection.createIndex({title: "text", content: "text"}, {weights: {title: 5}}) 执行后发现 content 字段没生效，其实是漏写了 content: 1 —— 权重对象里没出现的字段，默认权重为 1，但容易误以为被忽略。
- 权重只对声明为
"text"类型的字段有效；非 text 字段（如date或number）写进weights会被静默忽略 - 权重值必须是正整数，不能是小数或字符串；MongoDB 不校验类型，但非法值会导致整个
weights配置失效，回退到默认权重 1 - 使用 Robo 3T 或 mongosh 执行命令时，建议先用
db.collection.getIndexes()确认索引已存在且结构正确，再执行搜索验证
weights 参数影响的是 $text 查询的评分逻辑
权重不改变匹配行为，只改变每个文档的 score 值。比如 {title: "MongoDB", content: "fast database"} 在查询 "MongoDB" 时，如果 title 权重是 10、content 是 2，那么仅 title 匹配就比 content 匹配得分高得多——排序时自然靠前。
实际效果取决于你的查询方式：只有用 {$text: {$search: "..."}} 才触发权重计算；用普通 find({title: /MongoDB/}) 完全不受影响。
- 权重差异在多字段都命中时才明显。单字段匹配时，所有权重配置效果一致
- 评分公式是加权词频 × 字段权重，不是简单相加。短字段（如 title）天然词频低，高权重能补偿这一点
- 不要盲目拉高权重（比如设成 100）。权重是相对关系，
{a: 10, b: 1}和{a: 100, b: 10}实际效果几乎一样
复合全文索引字段顺序与权重无关，但影响索引大小和构建速度
你写 {title: "text", content: "text", tags: "text"} 还是 {content: "text", title: "text", tags: "text"}，对查询结果排序没区别——权重才是决定分数的关键。但字段顺序会影响索引元数据结构和构建时的内存占用。
真实场景下，把最常更新、最长文本的字段（如 content）放后面更稳妥。因为 MongoDB 构建全文索引时，会对每个字段做分词和倒排，长字段处理耗时更长，放末尾可略微降低首字段处理失败导致的中断风险。
- 字段数量越多，索引体积越大，磁盘和内存开销越明显。三个 text 字段的索引可能比单字段大 5–8 倍
- 如果某字段几乎不参与搜索（比如日志类字段），别加进全文索引——它只会拖慢构建、增大体积，权重再低也没意义
- 注意
text索引强制要求至少一个字段，且不支持与其他类型（如2dsphere）混用在同一索引中
验证权重是否生效，别只看排序结果
光看 find().sort({score: {$meta: "textScore"}}) 排序靠前，不能证明权重起作用。真正要确认，得查出具体 score 数值并比对。
执行带投影的查询：db.blog.find({$text: {$search: "coffee"}}, {score: {$meta: "textScore"}, title: 1, content: 1}).pretty()，观察不同文档的 score 是否符合权重预期（比如含 "coffee" 的 title 文档 score 明显高于仅 content 匹配的）。
- 权重生效的前提是查询词在多个字段中都出现。如果只在 high-weight 字段出现，低权重字段没匹配，那 score 差异主要来自词频，不是权重
- 用
explain()查看执行计划，确认indexName是你刚建的那个带 weights 的索引，而不是旧的默认 text 索引 - 重建索引后务必检查
db.blog.getIndexes()输出里的weights字段，避免因 JSON 格式错误（如逗号遗漏、引号不匹配）导致配置未写入
$text 查询中起作用，而很多团队误以为它会影响所有模糊搜索场景。
