可以，但仅限读操作；写阶段如$merge、$out等会报错，因事务只保证原子性写入，聚合框架本质是读取+计算流水线。
事务中能直接用 aggregate() 吗？
可以，但仅限读操作；任何写阶段（如 $merge、$out、$set 配合 $replaceRoot 修改文档）在事务内都会报错：Transaction numbers are only allowed on write operations 或更直白的 Command not supported inside a transaction。
根本原因：MongoDB 事务只保证「原子性写入」，而聚合框架本质是读取+计算流水线，只有显式触发写入的阶段才被事务上下文约束。
-
$match、$project、$group、$sort等纯读阶段完全可用 -
$lookup在事务中支持，但被关联集合不能是分片集合（除非使用$lookup的pipeline形式且目标集合在同分片） -
$unwind安全，但若源字段为null或缺失，会直接丢弃该文档（不是报错，但容易漏数据）
$match 在事务里必须加索引吗？
不是“必须”，但不加很可能卡住事务。事务内长时间运行的聚合会持有读锁（在 WiredTiger 引擎下是文档级，但扫描无索引字段仍会遍历大量文档），拖慢整个事务的提交速度，甚至触发 maxTimeMS 超时。
实操建议：
- 所有事务内
$match条件字段，优先建单字段或复合索引（尤其含$gt、$in、$eq的字段） - 避免在事务中用
$regex做前缀模糊匹配（^abc可走索引，abc不行），它会强制 collection scan - 用
explain("executionStats")检查事务外等效聚合的executionStages，确认stage是IXSCAN而非COLLSCAN
为什么 $group 在事务里常出内存超限？
因为 $group 阶段默认最多用 100MB 内存，事务本身不改变这个限制；而事务常用于处理关键业务数据，往往涉及中等规模中间结果（比如按用户 ID 分组统计当日订单），稍不注意就触发 errmsg: "Sort exceeded memory limit..."。
解决方法很明确：
- 加
{ allowDiskUse: true }到aggregate()的 options 参数里 —— 事务中允许磁盘暂存是安全的，不会破坏原子性 - 但注意：
allowDiskUse必须显式传入，事务上下文不会自动继承连接级设置 - 更优策略是前置
$match尽量缩小输入文档数，比依赖磁盘更高效
想在事务里“查完就改”，怎么衔接聚合和更新？
不能在一个 aggregate() 里混写读+写，得拆成两步：先聚合查出目标，再用查得的 _id 或业务键调用 updateOne() / updateMany()。
关键细节：
- 聚合结果必须转成 JS 对象（如
toArray()），不能直接把游标传给后续 update —— 游标在事务 commit 后失效 - 如果聚合输出的是嵌套结构（比如
{ _id: { uid: "...", date: "2026-04-14" }, total: 123 }），记得解构后拼进 update filter，别直接塞整个对象 - 高并发下注意：聚合查出的结果到执行 update 之间存在时间窗口，若业务要求强一致性，需在 update 中加条件校验（例如
{ $eq: "pending" }），避免覆盖他人已修改的状态
真正容易被忽略的是：事务内聚合的 $lookup 结果，若用于后续 update 的 filter，其字段值必须是确定的、非计算型的；比如不能拿 $lookup 出来的数组长度做条件（{ "refs.0": { $exists: true } } 可以，{ $size: "$refs" } 在 update filter 里不合法）。
