必须确保字段为Date类型，否则字符串按字典序比较会导致$gte/$lte查询失效；混存时需用聚合管道清洗并建索引，同时在写入层强制校验类型。
字段类型不一致时 $gte/$lte 查询失效
当 MongoDB 中同一字段混存 Date 对象和字符串（如 "2023-06-23"），用 $gte 和 $lte 做范围查询会返回错误结果——MongoDB 按字符串字典序比较，而非时间顺序。比如 "12/31/2022" 在字典序上大于 "01/01/2023"，但实际日期更早。
这种问题不会报错，只会静默返回空或错漏数据，排查时容易误判为业务逻辑问题。
- 用
db.collection.findOne()抽样检查字段类型：typeof doc.createdAt === "string"或doc.createdAt instanceof Date - 聚合中加
{$type: "$createdAt"}统计类型分布：db.collection.aggregate([{$group: {_id: {$type: "$createdAt"}, count: {$sum: 1}}}]) - 别依赖客户端格式化后再存——
new Date().toISOString()是安全的，但toLocaleDateString()输出字符串，必须避免
修复已混存的字符串日期字段
不能直接用 $convert 批量更新，因为部分字符串格式非法（如 "Jun 23, 2023" 或缺失年份），会导致操作中断或丢数据。
稳妥做法是分两步：先识别可安全转换的子集，再逐步清洗。
- 用正则匹配标准 ISO 格式字符串：
db.collection.updateMany({createdAt: {$regex: /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}/}}, [{$set: {createdAt: {$dateFromString: {dateString: "$createdAt"}}}}]) - 对非标准格式（如
"06/23/2023"），需先用应用层解析再写回，或用$dateFromString配format参数：{dateString: "$createdAt", format: "%m/%d/%Y"} - 更新后立即建索引：
db.collection.createIndex({createdAt: 1})，否则后续查询仍走全表扫描
防止新写入再出现类型混杂
Schema 不强制是 MongoDB 的特性，但业务层必须补位。光靠文档验证（validator）不够——它只拦写入，不拦已有脏数据，也不防驱动层自动转换。
- Node.js 中用 Mongoose 时，字段定义明确写
type: Date，并设required: true；避免type: String+ 手动转Date - 原生 driver 写入前做类型断言：
if (!(value instanceof Date)) throw new Error("createdAt must be Date") - 聚合管道里慎用
$toDate替代字段——它遇到非法字符串会转成null，导致条件丢失，应配合$cond判断兜底
聚合阶段中类型不一致引发的隐性错误
$dateToString、$dayOfMonth 等日期操作符输入必须是 Date 类型，若字段含字符串值，对应文档该字段计算结果为 null，且无警告。
例如按日分组时，混存字符串的文档会被归到 null 组，而不是报错或跳过。
- 在
$group前加校验 stage：{$addFields: {safeDate: {$cond: [{ $eq: [{ $type: "$createdAt" }, "date"] }, "$createdAt", null]}}} - 用
$facet分离正常/异常数据流，分别处理，避免污染主结果集 - 监控日志里留意
"cannot use $dateToString on value of type string"—— 这类 warn 在 MongoDB 6.0+ 默认不输出，需显式开启logComponentVerbosity
字段类型混杂的问题往往在查询变慢或结果突变时才暴露，但根因早已埋在写入路径里。修复重点不在“怎么改旧数据”，而在“如何堵住新数据的漏洞”——类型校验要落在 driver 层或 ORM 层，而不是等数据进库后再补救。
