MongoDB 3.6+ 使用 $dateFromString 将字符串转 Date 类型，需显式指定 format、处理 null/错误/时区，不支持模糊格式或 locale，应先清洗再转换。
字符串日期转为 Date 类型用 $dateFromString
MongoDB 3.6+ 提供了 $dateFromString，专门处理形如 "2023-10-05" 或 "2023/10/05T14:30:00Z" 这类字符串转成真正的 Date 类型。它比手动拼接 $concat + $dateFromParts 更可靠，也比用 JavaScript 的 $function 更高效且支持索引下推（如果字段有索引且管道可优化）。
常见错误是直接对字符串字段做 $gt 比较，结果永远为 false——因为字符串比较和日期比较逻辑完全不同。
-
input必须是字符串字段或表达式，不能是数字或空值；传入 null 或缺失字段会报错，需先用$ifNull或$cond处理 -
format参数不是可选的：即使字符串符合 ISO 标准（如"2023-10-05T08:30:00Z"），也必须显式指定，否则解析失败 - 支持的格式有限：例如
"%Y-%m-%d"、"%Y/%m/%d %H:%M:%S"，不支持模糊格式（如省略前导零的"2023-9-5"），此时需先用$replaceAll或正则预处理
处理不规范字符串得先清洗再转换
现实数据里常有 "Oct 05, 2023"、"05/10/2023"、甚至带多余空格或中文字符的字符串。MongoDB 原生不支持 locale 解析（比如识别 “十月”），也不能自动推断格式。
这时要分两步：先用字符串操作标准化，再喂给 $dateFromString。
- 用
$replaceAll统一斜杠/短横线，例如把"05/10/2023"→"2023-10-05"（注意年月日顺序需人工确认） - 用
$regexFind提取日期片段，再用$dateFromParts组装（适合格式混乱但结构固定的情况，如总含“年”“月”“日”字） - 避免在聚合中调用
$function做复杂解析——它无法利用索引，且在分片集群上可能触发全表扫描
$dateFromString 的错误处理必须显式写
聚合管道里任何一步出错都会让整个文档被丢弃（除非用 $cond 捕获）。而 $dateFromString 遇到无法解析的字符串默认抛异常，不是返回 null。
正确做法是包裹一层条件判断：
{
$addFields: {
parsedDate: {
$cond: {
if: { $eq: [{ $type: "$dateStr" }, "string"] },
then: {
$dateFromString: {
dateString: "$dateStr",
onError: null,
onNull: null,
format: "%Y-%m-%d"
}
},
else: null
}
}
}
}
-
onError和onNull必须显式设为null或默认值，否则遇到非法输入直接中断管道 - 不要依赖
$ifNull包裹$dateFromString输出——它只处理 null，不捕获解析异常 - 调试时可临时加
$addFields: { debug: { $dateFromString: { ... } } }看具体哪条文档崩了
时区问题容易被忽略
$dateFromString 默认按 UTC 解析。如果原始字符串是本地时间（如 "2023-10-05 14:30:00" 表示东八区），不指定时区会导致时间偏移 8 小时。
- 用
timezone参数显式声明，例如timezone: "Asia/Shanghai"或timezone: "+08:00" - 注意
timezone不能是变量字段（如"$tz"），只能是字面量字符串；若时区存于文档中，需用$switch映射成固定值 - 存储时建议统一转为 UTC 时间，查询时再按需转本地——避免后续所有聚合都得带时区参数
真正麻烦的不是语法，而是原始数据里混着多种格式、多种时区、还有大量脏数据。写聚合时别想着一步到位，先用 $facet 分组统计各格式占比，再针对性清洗。
