是，$out、$merge及事务内聚合会因主节点降级而中断；纯读聚合（如$match、$group）在readpreference: secondary时不受影响。
副本集选举时主节点角色切换会终止正在执行的写操作
选举本身不直接“中断”聚合，但主节点降级为从节点后，所有未完成的写操作（包括带写入的聚合）会立即报错并中止。MongoDB 的聚合管道如果包含 $out、$merge 或事务内聚合，本质是写操作，必须由主节点执行；一旦它在选举中失去主身份，连接会被强制关闭，客户端收到 NotPrimaryNoSecondaryOk 或 InterruptedAtShutdown 错误。
哪些聚合操作实际依赖主节点且易被中断
不是所有聚合都会被影响——只有涉及数据变更或跨文档持久化的聚合才真正受选举冲击：
-
$out：必须写入目标集合，强制路由到主节点；选举中目标节点降级 → 写失败 -
$merge：同样需要主节点确认写入，且可能触发唯一键检查、upsert 等原子操作 - 聚合嵌套在事务中（
session.startTransaction()后调用）：整个事务上下文绑定主节点生命周期，降级即中止事务 - 使用
writeConcern: { w: "majority" }的聚合：等待多数节点确认，选举期间同步链断裂，超时后报WriteConcernFailed
为什么从节点上的只读聚合通常不受影响
纯读聚合（如仅含 $match、$group、$sort 且无 $out/$merge）默认可在从节点运行，只要客户端设置 readPreference: secondary。这类操作不修改数据，也不依赖 oplog 同步状态，选举过程对从节点服务无干扰。但注意：若聚合语句显式指定 readPreference: primary，即使只是读，也会被路由到主节点，从而暴露在选举风险下。
避免聚合中断的关键配置与实践
真正可控的不是“阻止选举”，而是降低聚合对主节点的强依赖和提升容错能力：
- 非关键聚合尽量用
readPreference: secondaryPreferred，避开主节点单点 - 含
$out的聚合，提前预估执行时间；若 >30 秒，考虑拆成批处理 + 重试逻辑，捕获NotPrimary并重新发起 - 禁用
journal: false的节点上，oplog 写入延迟更高，选举更频繁——生产环境务必开启 journal - 不要在聚合中混用高一致性要求（如
readConcern: "majority"）和长耗时阶段（如大集合$lookup），二者叠加会显著拉长主节点持有锁的时间，放大选举敏感度
最常被忽略的一点：聚合是否中断，和它“多复杂”关系不大，而取决于它“是否写”以及“写时主节点是否稳”。一个 2 行的 $out 聚合，比一个跑 5 分钟但纯内存计算的 $group 更容易因选举失败。
