事务中聚合管道报错主因是误将聚合当事务写操作：$out、$merge等写阶段被禁止，因破坏原子性；$match无索引会拖垮事务；$and等裸用或漏cursor选项亦致错。
事务中执行聚合管道报错，绝大多数情况不是代码写错了，而是你误把聚合当成了“事务内可随意写的操作”——MongoDB 事务只允许原子性写入，而聚合本质是读取+计算流水线，写阶段（如 $out、$merge）天然被禁止。
为什么 $out 和 $merge 在事务里直接报错？
这两个阶段会触发跨文档、跨集合甚至跨分片的持久化写入，破坏事务的原子边界。MongoDB 服务端在解析聚合管道时，一旦检测到它们出现在事务上下文中，立刻拒绝执行，并返回类似 "Command not supported inside a transaction" 的错误。
-
$out绝对禁止：无论目标集合是否存在、是否在同一数据库，事务中调用即失败 -
$merge有条件禁止：即使目标集合与输入集合同属一个分片，也需满足writeConcern: { w: "majority" }；但该支持实际从 2026 年 6 月 9 日起才在部分版本中灰度上线，生产环境仍应视为不可用 - 注意：
$set+$replaceRoot等“看似只改字段”的组合，若最终导致文档重写（如修改了分片键），也会被拦截
为什么 $match 不报错却可能拖垮整个事务？
$match 本身安全，但它没索引时会触发全量扫描，而事务持有读锁期间，其他写操作会被阻塞。WiredTiger 虽是文档级锁，但无索引 $match 仍要遍历大量文档，极易超时或卡死。
- 所有事务内
$match涉及的字段，必须建索引（单字段或复合均可） - 避免
$regex前缀不固定（如/abc/），^abc可走索引，abc不行 - 用
explain("executionStats")验证等效查询是否命中IXSCAN，而非COLLSCAN
为什么升级 Java 驱动后 $and 突然报 "Unrecognized pipeline stage name: '$and'"？
这不是 MongoDB 服务端的问题，而是驱动层校验变严：$and 是查询操作符，不是聚合阶段。旧版驱动（如 3.8.1）可能容忍你把它直接加进管道，新版（4.6.1+）会严格检查阶段名白名单，发现 { "$and": [...] } 就直接拒掉。
- ✅ 正确写法：
Aggregates.match(Filters.and(...))—— 把$and包在$match里 - ❌ 错误写法：
pipeline.add(Filters.and(...))—— 驱动生成独立{"$and":[...]}阶段 - 其他逻辑操作符（
$or、$not）同理，不能裸用
为什么连 aggregate() 都不报错，却提示 "cursor option is required"？
MongoDB 3.6+ 协议强制要求聚合必须返回游标，否则视为非法请求。事务本身不改变这一约束，但容易忽略：你在事务 session 里调用 aggregate()，仍需显式传 { cursor: {} } 或用驱动封装好的方法（如 PyMongo 的 collection.aggregate(...).to_list() 内部已处理）。
- Shell 中必须写：
db.coll.aggregate([{$match:{}}], {cursor:{}}) - Java 驱动 4.6.1+ 若手动构造 Bson，漏掉
cursor选项会直接抛协议错误 - Node.js 驱动 v3.7.0 以前版本不会自动补
cursor:{}，需显式传参
真正棘手的从来不是“能不能做”，而是“看起来能做，实际在事务里悄悄失效”——比如 $lookup 关联分片集合、$unwind 遇到空字段静默丢数据、$group 内存超限却不报错只卡住。这些都不会立刻崩，但会在高并发或数据量上升时突然暴露。
