副本集聚合偶发因果一致性错误，根本原因是默认readConcern: "local"导致读取未同步的从节点；需显式启用会话、readConcern: "majority"及causalConsistency: true三者协同。
副本集聚合管道偶发因果一致性错误，根本原因不是聚合本身出错，而是默认读取行为没对齐因果顺序——readConcern: "local" 或未显式设置 readConcern 时，读操作可能落到尚未同步完最新写入的从节点上。
聚合操作默认不启用因果一致性保障
MongoDB 的聚合（aggregate）在副本集中默认使用 readConcern: "local"，这意味着它只保证读到某个节点本地已提交的数据，不保证该数据已被多数节点确认、也不保证与之前写入存在因果关系。哪怕你刚用 writeConcern: "majority" 写完一条记录，紧接着在同一会话中执行聚合，仍可能因路由到 lagging 的 secondary 而漏读。
- 现象：前端提交订单后立即查订单列表，偶尔查不到刚下的单
- 触发条件：聚合发起时，primary 已写入 oplog，但目标 secondary 还没拉取/应用该条目
- 关键点：
aggregate不自动继承上一个写操作的逻辑时间戳，除非显式开启会话和因果上下文
必须配合会话（Session）+ readConcern: "majority" + causal consistency flag
要让聚合“看到自己刚写的东西”，三者缺一不可：
- 用
startSession()创建逻辑会话，使后续操作可被标记为因果链的一部分 - 在聚合选项中显式指定
readConcern: { level: "majority" }，而非依赖默认值 - 调用
session.advanceClusterTime()（驱动自动做，但需确保驱动版本 ≥ 4.0 且服务端 ≥ 4.0） - 注意：
readConcern: "majority"本身不等于因果一致；只有在会话中启用causalConsistency: true才真正激活混合逻辑时钟传递
示例（Node.js 驱动）：
const session = client.startSession({ causalConsistency: true });
await session.withTransaction(async () => {
await collection.insertOne({ orderNo: "ORD-123" }, { session });
// 此处 aggregate 将带上 clusterTime 和 lastWrite
const result = await collection.aggregate([
{ $match: { orderNo: "ORD-123" } }
], { session, readConcern: { level: "majority" } }).toArray();
});
分片集群下聚合更易丢因果链
在分片集群中，mongos 会把聚合拆解并分发到各分片执行。若未绑定会话，不同分片可能各自从不同 secondary 读取，导致跨分片结果不满足因果顺序。即使单个分片内满足 majority，全局聚合结果仍可能“回退”。
- 典型表现：用户更新资料后查个人主页，头像字段是旧的，昵称却是新的
- 根本限制：MongoDB 不支持跨分片的强因果一致性聚合；
readConcern: "majority"只在分片内部生效 - 缓解方式：对关键聚合，强制路由到 primary（
readPreference: "primary"），或改用带$lookup的单分片聚合避免跨片 - 注意：
sharded aggregate不支持readConcern: "linearizable"，该级别仅限单文档读
最容易被忽略的是：因果一致性必须由客户端显式开启并全程维持，服务端不会替你“记住”上一次写了什么。一旦会话中断、连接复用、或驱动降级到老版本，clusterTime 就断了——这时候聚合看起来“随机失败”，其实只是因果链意外终止。
