权重字段必须参与复合索引，顺序为过滤字段在前、排序字段在后，方向需与sort一致；字符串权重应转数值避免字节序排序错误。
直接用 sort() 按权重字段排序，但不加索引或建模不当，查着查着就卡住、OOM 或触发 Sort exceeded memory limit 错误——这是最常见也最容易被忽视的性能断点。
权重字段必须参与索引，且顺序不能错
MongoDB 的排序只有在能“顺着索引走”的前提下才不走内存排序。如果只对 score 字段建了单字段索引，但查询同时带了 status: "active" 过滤条件和 sort({ score: -1 })，那这个索引大概率不会被用于排序（explain 里能看到 "stage": "SORT"）。
- 复合索引字段顺序必须匹配查询模式：过滤字段在前，排序字段在后，例如
db.items.createIndex({ status: 1, score: -1 }) - 如果还要支持按时间兜底排序（比如 score 相同再按
createdAt降序），索引就得写成{ status: 1, score: -1, createdAt: -1 } - 索引方向（
1或-1）要和sort()中一致；混合方向（如{ a: 1, b: -1 }）可以支持sort({ a: 1, b: -1 })，但不支持sort({ a: 1, b: 1 })
避免字符串权重字段的隐式二进制排序陷阱
如果你的权重是存成字符串（比如 "95.5"、"102"），默认 sort({ weight: 1 }) 会按字节序排："102" "95.5" —— 因为 '1' '9'。这不是 bug，是 BSON 类型比较规则决定的。
- 要么把权重字段统一存为数字类型（推荐）
- 要么强制用 collation 启用数值感知排序：
.sort({ weight: 1 }).collation({ locale: "en", numericOrdering: true }) - 注意：加了
collation的查询，必须用对应 collation 创建索引，否则索引失效
聚合管道中 $sort 配合 $limit 要前置
当排序逻辑嵌在聚合里（比如先 $match 再加权计算再 $sort），$sort 阶段默认会把所有中间结果拉进内存。数据量稍大就崩。
- 把
$limit尽可能往前放，比如在$sort之前加个粗筛$limit(1000)，能极大缓解内存压力 - 更稳的做法是：把加权逻辑提前到索引建模里，例如预计算字段
final_score: { $add: [ "$base_score", { $multiply: [ "$boost", 0.3 ] } ] }，然后直接对final_score建索引并sort - 别依赖
$sort+$skip做深度分页；超过几千条偏移时，改用游标式分页（find().sort().gt(last_score)）
排序一致性问题：重复权重值导致翻页错乱
当多个文档 score 完全相同时，MongoDB 不保证它们之间的相对顺序稳定——尤其跨查询、跨分片时。用户下拉刷新，同一批数据可能前后两页重复或漏掉。
- 唯一解法是在
sort()里补一个确定性字段，最常用的是_id：.sort({ score: -1, _id: 1 }) - 注意：补的字段必须有索引支撑，否则仍会触发内存排序；所以最终索引往往是
{ status: 1, score: -1, _id: 1 } - 如果业务允许，用时间戳字段（如
updatedAt）替代_id更直观，但需确保该字段非空且单调递增
权重排序真正难的不是语法，而是把查询意图、索引结构、数据类型、分页方式四者对齐；漏掉任意一环，都可能让排序从毫秒级退化成秒级甚至超时。尤其当权重来自运行时计算或多个来源拼接时，优先考虑固化到字段再建索引，而不是硬扛聚合管道里的动态排序。
