MongoDB 5.0时序集合不支持自动重算或迟到数据修正，迟到数据可正常写入（只要timeField为有效Date类型），但需应用层显式重跑聚合并做幂等控制，避免TTL误删或压缩率下降。
MongoDB 5.0 的时序集合（time-series collection）本身不提供“重算”或“迟到数据修正”能力——它没有事件时间回填机制、不支持窗口水印、也不维护状态用于重新触发聚合。所谓“重算”，必须由应用层显式控制。
迟到数据写入时序集合会直接失败或被静默丢弃？
不会失败，但行为取决于你是否严格校验 timeField 值：
-
timeField必须是Date类型且非空；如果插入{ ts: null, temp: 22.1 }，文档会被拒绝（报错"timeField must be of type date"） - 如果插入
{ ts: ISODate("2024-01-01T00:00:00Z"), temp: 22.1 }，哪怕当前已是 2026 年，MongoDB 仍接受——它只校验类型和存在性，不校验时间是否“过期” - 但注意：TTL 清理只按物理写入时间（或
timeField值）推进，不会因“迟到”而跳过或重排
聚合查询中如何让迟到数据参与计算？
关键在于：聚合管道本身不区分“实时写入”和“历史补录”，只要文档在集合中、满足 $match 条件，就会被纳入计算。但有三个易踩的坑：
- 如果你用
$dateTrunc按granularity: "minutes"分组，而补录数据的ts落在已聚合过的分钟区间内，它会自然进入对应分组——无需额外操作 - 但若你依赖
$group+$_id: { $dateToString: { format: "%Y-%m-%d %H:%M", date: "$ts" } }这类手动格式化，要注意时区一致性；$dateTrunc默认用 UTC，而$dateToString若没指定timezone，可能错位 - 复合 TTL 索引（如
{ device: 1, ts: 1 }）不会阻止迟到数据写入，但可能在你没注意时，把刚补录的数据连同旧数据一起删掉——因为 TTL 是按ts字段值 +expireAfterSeconds计算过期时间的
有没有办法触发“重聚合”？
没有内置机制。MongoDB 不保存聚合中间状态，也不支持物化视图自动刷新。你需要自己做两件事：
- 把聚合逻辑封装成可重复执行的脚本（例如用
mongosh调用db.sensors.aggregate([...])），并加幂等控制（比如结果写入带_id: { device: "...", window_start: ... }的独立集合） - 对补录数据，明确界定影响范围：比如只重跑
ts在ISODate("2026-04-10")到ISODate("2026-04-12")的窗口，避免全量扫表 - 不要依赖时序集合的“自动优化”来加速重算——底层 bucket 组织是按写入顺序和
granularity预设的，补录数据大概率落在新 bucket 中，与原始数据物理隔离，反而可能降低局部性
真正容易被忽略的是：时序集合的压缩优势只对连续、密集写入有效；大量离散补录会让 bucket 稀疏，实际存储反而比普通集合更大。补数据前，先评估写入节奏和 granularity 是否匹配。
