事务中禁用$out和$merge是MongoDB服务端硬性限制，因其元数据变更不可回滚；唯一可行方案是聚合后应用层insertMany；最终一致性场景应改用change stream+幂等写。
事务中使用$out会直接报错「Command not supported inside a transaction」
这不是驱动或语法写错了，而是 MongoDB 服务端的硬性限制。从 4.2 开始，$out 就被明确排除在事务支持范围之外——哪怕你用 db.collection.aggregate([...]) 包裹，只要在 session.startTransaction() 之后调用，立刻失败。
根本原因在于：$out 本质是写入目标集合（可能覆盖、重命名、甚至隐式创建），它触发的是非幂等的元数据变更和存储层重写，与事务要求的“可回滚性”冲突。MongoDB 的事务快照机制无法安全撤回一次集合级覆盖操作。
- 错误信息固定为：
CommandNotSupported: $out is not allowed in transactions - 即使目标集合已存在、且有写权限，也无效
-
$merge同样被禁止（4.2+ 引入，但不支持事务内使用）
为什么不用$merge替代$out？它在事务里也不行
$merge 虽然比 $out 更安全（支持 upsert、字段级更新、避免全量覆盖），但它仍涉及跨集合的写入协调和潜在的索引更新，在事务上下文中同样不可回滚。MongoDB 明确将 $merge 和 $out 归为同一类“DDL-adjacent 写操作”，一并禁用。
-
$merge在事务中会报同样的CommandNotSupported错误 - 它依赖目标集合的现有结构和索引状态，而事务 snapshot 下无法保证该状态在 rollback 时可逆
- 即便你手动建好目标集合、预设好索引，
$merge仍被拒绝——限制在协议层，不看前提条件
真正可用的事务内聚合写入方案：只用$facet + 内存组装 + 单次insertMany
如果必须在事务中完成“聚合 → 写入另一集合”的逻辑，唯一可行路径是把聚合结果拉到应用层，再用 session 控制写入。这意味着放弃管道内写，改用两阶段协调：
- 第一阶段：在事务 session 中执行纯读聚合（不含
$out/$merge），用$facet或多次find拆解逻辑，最终得到内存中的文档数组 - 第二阶段：在同一
session中调用collection.insertMany(docs, {session})或updateMany等原子写操作 - 注意：不能用
bulkWrite混合多种操作——部分操作可能绕过 session 控制，导致事务不一致
示例片段（Node.js）：
const docs = await sourceCollection.aggregate([
{ $match: { status: "active" } },
{ $group: { _id: "$category", total: { $sum: "$amount" } } }
], { session }).toArray(); // ← 仅读，合法
await targetCollection.insertMany(docs, { session }); // ← 同一 session 写入，事务内原子
跨事务同步集合的现实取舍：用change stream + 幂等写代替$out
如果你原本依赖 $out 做定时汇总（如每小时订单统计写入 hourly_summary），那应该放弃“单事务强一致”幻想，转向最终一致性模型。这是生产环境更健壮的做法：
- 用独立定时任务跑聚合，输出到临时集合（如
hourly_summary_tmp） - 通过
change stream监听该临时集合的写入，触发下游幂等更新：比如updateOne({ hour: ... }, { $set: ... }, { upsert: true }) - 或用
renameCollection原子切换（但注意：renameCollection本身也不能在事务中执行） - 关键点：所有下游写操作必须带业务主键 +
upsert: true，容忍重复触发
这种模式绕开了事务限制，也更适应分片集群和高并发场景——$out 在分片集上本就受限（需 targeting 所有分片），而 change stream + 幂等写天然支持水平扩展。
真正容易被忽略的是：$out 看似“一行代码搞定”，实则掩盖了写入冲突、并发覆盖、权限粒度等深层问题。一旦业务需要多源写入、按租户隔离、或灰度发布，硬塞进事务只会让问题延后爆发。
