在 MongoDB 中，$dateToString 的格式化参数必须使用 C 语言风格的 %Y-%m，而非常见的 YYYY-MM。因为 %Y 代表四位年份，%m 代表补零的月份。如果误用 YYYY-MM，会导致字符串原样输出，从而使得分组统计失效。
先来说一个最常见的误区：很多开发者在用 $dateToString 做日期格式化时，习惯性地写出 YYYY-MM，结果发现分组后的字段名变成了“YYYY-MM”这个字符串本身，所有文档都被强行归入同一个假分组。原因很简单——MongoDB 的 $dateToString 并不支持 ISO 标准写法，它只认 C 语言风格的格式符。正确的写法是 "%Y-%m"，其中 %Y 输出四位年份，%m 输出补零的两位月份。
几个容易混淆的细节：
%Y是四位年份（如 2024），%y是两位（24），切勿混用%m是补零月份（01），Linux 风格的%-m在 MongoDB 中不被支持，无法去除前导零- 如果时间字段本身是字符串而非
Date类型，需要先用$dateFromString进行转换，否则$dateToString会直接报错，或返回null
在聚合管道中如何安全地按月份对 created_at 字段进行分组
不能直接把原始时间戳丢进 $group 里，必须先将其标准化为“年月字符串”。关键点在于处理空值、非法日期，以及——时区问题。
一个常见的失误是忘记指定时区，导致北京时间凌晨的数据被误算到上个月。因此聚合语句中需要显式添加 timezone: "Asia/Shanghai"。另外，用 $cond 过滤掉无效的 null 或非法日期，避免干扰计数准确性。
一个典型的分组片段如下：
{
$group: {
_id: {
$dateToString: {
format: "%Y-%m",
date: "$created_at",
timezone: "Asia/Shanghai"
}
},
count: { $sum: 1 }
}
}
按月分组后如何排序并限制结果数量
分组后的 _id 是类似 "2024-03" 的字符串，按字典序排序即可等价于按时间先后排列。这一规律在跨年时同样成立（如 "2023-12" 小于 "2024-01"）。但请注意：如果当初格式写成了 "%m-%Y"，那么字典序就会错乱，例如 "01-2024" 会排在 "12-2023" 前面。
若要获取最近 6 个月的数据，推荐的操作顺序是：先 $group，再 $sort，最后 $limit。这个顺序不能颠倒——如果先 $limit 再分组，截断的是原始文档而非分组后的月份，结果将不符合预期。
- 升序取最近 6 个月：
{$sort: {_id: 1}}+{$limit: 6} - 降序取最近 6 个月：
{$sort: {_id: -1}}+{$limit: 6}
性能隐患：索引对 $dateToString 分组是否有加速作用
答案很明确：没有。MongoDB 无法利用普通日期索引来优化 $dateToString 这种运行时计算表达式。每次分组都需要全表扫描，一旦数据量增大，性能瓶颈就会凸显。
解决思路是“空间换时间”：在写入或更新时，通过应用层或变更流同步维护一个冗余字段 year_month（例如存为 "2024-03"），然后对该字段建立索引：
db.collection.createIndex({ year_month: 1 })
这样聚合查询就可以走索引扫描，尤其是在集合庞大且只需查询最近几个月时，性能差距非常显著。当然，代价是需要维护冗余字段的一致性——如果忘记更新，统计结果就会出错，那比速度慢更严重。
归根结底，真正棘手的不是写出一个能跑的聚合语句，而是确保时间字段类型干净、时区意识明确，以及在面对百万级数据时，是否有勇气将计算逻辑从查询层迁移到写入层。
