$dateToString不能解决根本问题，因为它仅转换输出格式，不修复数据层类型混杂（Date/string/number并存）导致的查询、排序、索引失效；须先查类型、备份、停写，再统一转为BSON Date并重建索引。
为什么 $dateToString 不能解决“查询返回日期格式不一致”的根本问题
直接用 $dateToString 在聚合阶段转换字段，确实能让返回结果里出现字符串格式的日期（比如 "2026-05-12"），但它只是把 BSON Date 转成字符串再吐出来——原始字段在数据库里还是 Date 类型，而你真正遇到的“不一致”，往往发生在字段本身类型混杂：有的存的是 Date，有的是 string，甚至还有 number（时间戳）。这时候光靠查询时转，掩盖不了数据层的混乱，后续所有范围查询、排序、索引都会出错。
先确认字段真实类型：别信字段名，要看 $type
执行以下聚合，快速摸清 created_at 字段到底存了哪些类型：
db.collection.aggregate([
{ $group: {
_id: { $type: "$created_at" },
count: { $sum: 1 }
}
}
])
常见返回可能包括："date"、"string"、"double"（时间戳）、"int"。只要结果里不止一种类型，就说明数据已污染——$dateToString 对非 Date 类型会静默返回 null 或报错，无法兜底。
修复数据前必须做三件事
- 备份集合：
db.collection.copyTo("collection_backup_20260512")（或用mongodump） - 停写入服务，或确保修复期间无新文档插入（否则刚修好又被写歪）
- 明确统一目标格式：全部转为 BSON Date，并使用 ISO 8601 字符串（如
"2026-05-12T00:00:00.000Z"）初始化，避免本地时区干扰
批量修复混合类型字段的可靠写法
假设你想把 created_at 中所有 string 和 number 类型都转成标准 Date，且忽略无法解析的值：
db.collection.updateMany(
{ "created_at": { $type: { $in: ["string", "double", "int"] } } },
[ {
$set: {
"created_at": {
$cond: {
if: { $eq: [{ $type: "$created_at" }, "string"] },
then: { $dateFromString: { dateString: "$created_at", onError: "$$REMOVE" } },
else: { $dateFromParts: { year: { $year: { $multiply: ["$created_at", 1000] } }, month: { $month: { $multiply: ["$created_at", 1000] } }, day: { $dayOfMonth: { $multiply: ["$created_at", 1000] } }, hour: { $hour: { $multiply: ["$created_at", 1000] } }, minute: { $minute: { $multiply: ["$created_at", 1000] } }, second: { $second: { $multiply: ["$created_at", 1000] } } } }
}
}
}
}
]
)
注意：$dateFromString 要求字符串符合 ISO 格式（如 "2026-05-12" 或 "2026-05-12T11:54:00Z"），对 "05/12/2026" 这类格式会失败；$dateFromParts 适用于毫秒级时间戳（number 类型）。两者都配 onError: "$$REMOVE" 可跳过脏数据，避免中断。
修复后务必重建索引：db.collection.createIndex({ "created_at": 1 })，旧索引对混合类型无效。
真正棘手的不是怎么转，而是字段里混着几种类型还长期没被发现——等业务开始按天统计、查趋势、做告警时，才发现 $gte 查不到昨天的数据，或者 $sort 排序乱序。这类问题一旦发生，只靠查询层补救，就像用胶带缠漏水的水管。
