根本原因是MongoDB不保证created_at写入时间严格单调递增，同一秒内多条写入可能因副本延迟、批量插入或应用层误差导致后写文档时间≤前一条；实操应组合created_at与_id复合查询，或直接用_id升序拉取确保不漏不重。
为什么 find() 加 $gt 时间戳不总能保证增量准确？
直接用 created_at: { $gt: last_sync_time } 看似合理，但实际容易漏数据。根本原因是：MongoDB 不保证写入时间严格单调递增——同一秒内多条写入可能因副本集延迟、批量插入顺序、或应用层生成时间戳误差，导致后写入的文档 created_at 反而 ≤ 前一条。尤其在高并发或分片集群下更明显。
实操建议：
- 永远不要只依赖单字段
created_at作为唯一增量依据 - 若必须用时间戳，优先使用 MongoDB 自带的
_idObjectId 中的时间部分（它由写入节点生成，更可靠） - 生产环境强烈建议组合使用：
created_at+_id作为复合条件，避免时间戳重复时的边界问题
如何用 _id ObjectId 实现稳定增量拉取？
ObjectId 的前 4 字节是 Unix 时间戳（秒级），后 5 字节含机器标识、进程 ID 和自增计数器，天然具备写入时序性。只要按 _id 升序查询，就能严格保序且不漏不重。
实操建议：
- 记录上一次同步的最后
_id（比如ObjectId("65a1b2c3d4e5f67890123456")） - 下次查询用：
{ _id: { $gt: last_id } }，无需任何索引额外开销（_id默认有唯一索引） - 注意：不能用
$gte，否则会重复拉取上次末尾那条；也不能跳过_id直接用时间戳推算，因为 ObjectId 时间部分只精确到秒，无法定位到毫秒级位置
时间戳字段 + _id 复合查询怎么写才安全？
当业务强依赖 created_at（比如按业务时间归档），又想规避时间重复问题，必须把时间条件和 _id 绑定成“时间优先、ID兜底”的逻辑。
实操示例（以 Node.js + MongoDB Driver 为例）：
// 上次同步记录：{ created_at: ISODate("2024-01-01T00:00:00Z"), _id: ObjectId("65a1b2c3d4e5f67890123456") }
const filter = {
created_at: { $gt: lastSync.created_at },
// 同一秒内可能有多条，用 _id 排除已同步过的
$or: [
{ created_at: { $gt: lastSync.created_at } },
{
created_at: lastSync.created_at,
_id: { $gt: lastSync._id }
}
]
};
关键点：
- 这个
$or结构确保：所有时间严格大于上次的文档全取；时间相等的只取_id更大的 - 必须给
created_at字段建索引（如{ created_at: 1, _id: 1 }），否则$or可能触发全表扫描 - 如果
created_at是字符串格式（如 "2024-01-01 12:00:00"），务必转成ISODate()再查，否则字符串比较会出错
聚合管道里做增量窗口查询要注意什么？
用 $lookup 或 $facet 做复杂关联时，别在 pipeline 开头就用 $match 过滤时间——这会导致后续阶段（如 $group）丢失未满足时间条件但实际需要的中间数据。
正确做法是：尽可能把增量过滤放到 pipeline 最后，或拆成两步。
- 先用
_id范围拉出原始文档（快、准、可索引） - 再在内存或应用层做时间字段校验（避免误判）
- 如果非要在聚合里做，用
$expr配合$gt，但注意$expr无法利用索引，性能差
真正棘手的不是语法，而是时间字段来源不可控——比如从 Kafka 消息里解析的时间、前端传入的时间、日志打点时间，这些都可能比 MongoDB 写入时间晚几毫秒。增量逻辑必须容忍这种微小偏移，而不是迷信“时间戳=写入顺序”。
