$last 不一定能拿到“最新”记录，因为它仅取数组末位元素，不保证时间或业务意义上的最新；必须先用 $sort 按时间字段降序排序，再 $group + $last，否则结果不可靠。
为什么 $last 不一定能拿到“最新”记录？
$last 只是取数组中最后一个元素，它不关心时间戳、插入顺序或业务意义上的“最新”。MongoDB 的 $group 阶段本身不保证文档输入顺序，除非你显式用 $sort 预排序。如果没排序就直接 $last，结果取决于 pipeline 输入的物理顺序（可能每次都不一样）。
常见错误现象：$last: "$createdAt" 返回的日期看起来“随机”，甚至比 $first 还早。
- 必须在
$group前加$sort，按时间字段（如createdAt）降序排列 - 时间字段需是
Date类型或能正确比较的数值（如毫秒时间戳），字符串格式（如"2024-01-01"）可能字典序错乱 - 若用
$push收集整个文档再$last，内存开销大，尤其分组内文档多时
正确写法：$sort + $group + $last 组合
标准链路就是先排好序，再分组取末位。这是最稳妥、语义最清晰的做法。
示例：按 userId 分组，取每个用户最新一条订单
Multi-Brain Protocol
下载
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
[
{ $sort: { createdAt: -1 } },
{
$group: {
_id: "$userId",
latestOrder: { $last: "$$ROOT" },
latestAmount: { $last: "$amount" }
}
}
]
-
$$ROOT表示整条文档，适合需要完整字段的场景 - 如果只取单个字段（如
status），直接写$last: "$status"更轻量 - 注意
$sort必须在$group之前，位置颠倒就失效
替代方案：用 $max 替代 $last（更高效）
如果“最新”仅由时间字段定义（比如 createdAt 是 Date 类型），$max 更直接且性能更好——它不依赖顺序，也不构造中间数组。
示例：同样按 userId 分组，只取最大时间戳和对应金额
[
{
$group: {
_id: "$userId",
maxTime: { $max: "$createdAt" },
latestAmount: {
$max: {
$cond: [{ $eq: ["$createdAt", { $max: "$createdAt" }] }, "$amount", null]
}
}
}
}
]
-
$max本身不能跨字段取值（比如 max time 对应的 amount），所以第二个字段得用$cond配合嵌套$max实现，略复杂 - 若只需时间戳和少量字段，
$max+$first（配合预排序）通常比纯$last更省资源 - 聚合管道里避免多次
$max: "$createdAt"，可先用$addFields提前算好再引用
容易被忽略的坑：分片集合与内存限制
在分片集群上，$sort + $group 可能触发 Sort exceeded memory limit 错误，尤其当某 userId 关联成千上万条记录时。
- 确保
createdAt字段有索引（{ userId: 1, createdAt: -1 }复合索引效果最佳） - 加
$limit在$sort后（如只取每用户最近 100 条）能大幅降低内存压力 - 生产环境慎用
$last: "$$ROOT"，优先投影必要字段，避免传输冗余数据
真正麻烦的是时间字段不准——比如客户端写入的 createdAt 有误差，或用了 new Date() 但没同步 NTP。这时候 $last 拿到的“最新”其实是错的，得从源头校准时间。
