时间序列集合不支持多文档事务，因底层桶模型无法保证跨bucket操作的原子性与一致性，任何涉及该集合的事务均会报错“Transactions are not supported on time-series collections”。
时间序列集合不支持多文档事务，这是 MongoDB 5.0 中明确的限制，不是配置问题，也不是驱动或语法能绕过的。
为什么 session.startTransaction() 在 time-series 集合上会报错
当你对 time-series 集合执行 session.startTransaction() 并尝试写入时，MongoDB 会直接返回错误：
Command failed with error 263 (InvalidNamespace): "Transactions are not supported on time-series collections"
这个错误发生在服务端，驱动层无法掩盖。根本原因是：time-series 集合底层使用的是“桶（bucket）”存储模型，每个 bucket 文档封装了多个时间点数据，事务引擎无法在不破坏一致性前提下对这种聚合结构加锁或回滚。
- 即使你只插入单条文档，MongoDB 仍需将其归入某个 bucket，并可能触发 bucket 创建、拆分或更新——这些都不是原子操作
-
find/updateOne等常规操作可正常执行，但它们是单文档语义，不参与事务上下文 - 跨集合事务中若包含 time-series 集合，整个事务会立即失败，不会部分提交
哪些操作看似“事务性”，实则只是单文档保障
time-series 集合支持的写操作（如 insertOne、updateOne、deleteOne）都仅保证单文档级原子性，和普通集合一样，但和事务无关：
-
insertOne插入一条时间点数据 → 实际被写入对应 bucket 文档的data数组中，该数组更新是原子的 -
updateOne匹配timeField和metaField→ 只能更新 bucket 内部某条子文档，不能跨 bucket - 没有
findOneAndUpdate的事务等价物；所有这类操作都不受session控制
替代方案：用普通集合 + 应用层逻辑模拟事务边界
如果你必须在时间维度数据上实现跨文档一致性（比如“同时更新传感器元数据 + 对应时序数据”），只能放弃 time-series 集合，改用普通集合并自行管理：
- 把时间戳存为
ISODate字段（如ts: ISODate("2023-09-01T00:00:00Z")），配合location等元字段 - 手动创建复合索引：
{ location: 1, ts: 1 }，性能接近 time-series 的隐式索引 - 用
session.startTransaction()包裹对元数据集合和时序集合的写入（两者都必须是普通集合） - 注意：这会失去 time-series 的压缩、自动分桶、
$timeSeries聚合阶段等优化能力
真正容易被忽略的是：即使你在应用里封装了“写时加锁”或“两阶段提交”，只要底层用了 time-series 集合，就不存在事务语义。MongoDB 不会警告、不会静默降级，而是硬性拒绝——这点在设计初期就必须确认，不能等到压测阶段才发现。
