date类型是唯一可靠的选择，因字符串在查询、索引和时区处理上全面失效；字符串时间字段会触发全表扫描，且字典序比较导致日期逻辑错误。
Date 类型是唯一可靠的选择。字符串看似方便，实则在查询、索引、时区处理三方面全面失效。
字符串时间字段会触发全表扫描
当你对一个存为字符串的 created_at 字段执行 { created_at: { $gte: "2026-07-01T00:00:00Z" } }，MongoDB 只能做字典序比较——"2026-07-2T00:00:00Z"（7月2日）会被判定小于 "2026-07-15T00:00:00Z"（7月15日），因为第9位字符 '2' '1'。B-tree 索引完全无法加速这类比较，强制全集合扫描。
而 Date 类型在底层是 64 位毫秒时间戳，索引可直接按数值范围跳转，$gte/$lte 查询稳定落在 O(log n) 复杂度内。
- 字符串字段加索引 ≠ 日期范围查询有效索引
-
explain("executionStats")中若看到"totalDocsExamined"接近集合总数，基本就是字符串陷阱 - 即使字符串格式统一为 ISO 8601，也无法改变其字节比较本质
new Date() 和 Date() 在 shell 中行为完全不同
MongoDB Shell 里：new Date() 返回 ISODate 对象（即 BSON Date），而裸调 Date() 返回字符串。这是最隐蔽的踩坑点之一。
例如：
db.logs.insertOne({ ts: new Date() }) // ✅ 存为 Date 类型
db.logs.insertOne({ ts: Date() }) // ❌ 存为字符串，值类似 "Mon Jul 21 2026 15:35:00 GMT+0800 (CST)"
- Node.js 驱动中同理：
new Date()→ BSON Date；date.toISOString()或date.toString()→ 字符串 - Mongoose schema 中必须显式声明
type: Date，否则默认不校验，容易混入字符串 - 用
typeof doc.ts === 'object' && doc.ts instanceof Date可现场验证字段类型
时区逻辑必须由 Date 类型承载
所有正确的时间业务都依赖“语义化时间点”，而非“本地字符串快照”。比如查“北京时间今日 0 点”，用字符串方案你得在应用层手动计算 UTC 偏移、处理夏令时、拼接字符串；而用 Date 类型，可直接用聚合表达式：
{$dateFromParts: { year: {$year: "$ts"}, month: {$month: "$ts"}, day: 1, timezone: "Asia/Shanghai" }}
更关键的是：MongoDB 内部始终以 UTC 毫秒数存储 Date，驱动层（如 Node.js 的 mongodb driver）自动完成时区转换，避免应用层重复解析和歧义。
- 字符串若缺
Z或时区标识（如"2026-07-21T15:35:00"），根本无法确定它代表哪个时区的时间点 -
$dateToString是输出格式化工具，不是存储替代方案；它只能用在$project阶段，不能用于$match - 前端接收
Date类型字段后，new Date(doc.ts)天然适配用户本地时区，无需额外解析
findOne() + typeof 和 getConstructor().name 实际检查文档字段类型，别信文档结构描述或 schema 注释。
