根本原因是mongodb只存储utc时间戳且不保存时区信息；所有日期写入前被自动转为utc，查询时需将业务时间范围显式转换为utc再构造条件，避免字符串比较或隐式时区解析。
MongoDB 查询日期字段时出现时区偏差，根本原因只有一个：它**只存 UTC，不存时区信息**。你看到的“差8小时”，不是 bug，是设计使然。
所有日期都强制转成 UTC 存储
MongoDB 的 Date 类型底层是 BSON Date，本质就是一个从 Unix 纪元开始的毫秒数——纯 UTC 值。无论你用 new Date("2026-09-07T14:00:00+08:00") 还是 new Date("2026-09-07T06:00:00Z")，最终写入数据库的都是同一个毫秒数，对应 2026-09-07T06:00:00Z。
- Node.js 驱动会自动把传入的本地时间（如
datetime.now()）按系统时区转成 UTC 再存；若传的是 naive datetime（tzinfo is None），就直接当 UTC 处理——这正是 Python 里“少8小时”的源头 - Java 驱动同理：
LocalDateTime不带时区，必须显式用ZonedDateTime.withZoneSameInstant(ZoneOffset.UTC)转换后才安全 - 浏览器 JS 的
new Date()默认解析为本地时区，再转 UTC 存，所以东八区用户输"2026-09-07"，实际存的是2026-09-06T16:00:00Z
查询时没做时区对齐，$gte/$lt 就会错
用字符串写 ISODate("2026-09-07T00:00:00+08:00") 查询，看似指定了北京时区，但老版本驱动或 Data API 可能根本不认 +08:00，直接截断或报错；更常见的是你本意查“9月7日全天”，却写了：
{"createdAt": {"$gte": "2026-09-07T00:00:00Z", "$lte": "2026-09-07T23:59:59Z"}}
问题在于："2026-09-07T23:59:59Z" 是 UTC 时间，对应北京时间是 9月8日早上7:59:59，而你真正想覆盖的“9月7日北京时间 00:00–23:59”应转为 UTC 是 "2026-09-06T16:00:00Z" 到 "2026-09-07T15:59:59Z"。
- 推荐统一用「左闭右开」区间：
$gte+$lt，例如查北京 9月7日：用"2026-09-06T16:00:00Z"和"2026-09-07T16:00:00Z" - 别依赖可视化工具显示设置（如 Robo3T 的 Local Timezone）来“修复”查询逻辑——那只是前端渲染，不影响 filter 行为
- 用
new Date().toISOString()生成查询时间，确保字符串自带Z，避免隐式时区解析歧义
字段类型混用导致字符串字典序比较
如果历史数据里有的日期是 Date 类型，有的是字符串（比如 "2026-09-07 14:00:00"），那么 $gte 在混合类型字段上会失效——MongoDB 按 BSON 类型优先级排序，String 和 Date 不可比，查询可能全漏或部分命中。
- 用
db.collection.find({ createdAt: { $type: "string" } })扫描残留字符串字段 - 迁移时用聚合管道强制转类型：
{$set: {createdAt: {$dateFromString: { dateString: "$createdAt" } } }}（需确保字符串格式统一） - 应用层写入前加校验：
if (!(date instanceof Date) || isNaN(date.getTime())) throw new Error("invalid date")
最易被忽略的一点：时区转换不是数据库该干的事，而是读写两端的契约。存的时候确保传的是 aware datetime 或明确 UTC 时间戳，查的时候把业务需求的时间范围先转成 UTC 再构造 filter——中间跳过任何“自动推断”环节，才能稳。
