MongoDB 的快照读是事务内默认行为，由 WiredTiger 基于 MVCC 自动提供，无需显式设置隔离级别；事务外使用 readConcern: "snapshot" 需满足副本集或分片集群等前提条件。
快照读不是 MongoDB 的隔离级别配置项
MongoDB 不支持像 SQL 数据库那样通过 SET TRANSACTION ISOLATION LEVEL SNAPSHOT 显式声明隔离级别。它的「快照读」能力是事务内部默认行为，由存储引擎（WiredTiger）在多版本并发控制（MVCC）基础上自动提供——事务启动瞬间会捕获一个一致的全局快照（即所有已提交数据的逻辑时间点），后续读操作都基于该快照，不加锁、不阻塞写入。
这意味着你无法「切换」隔离级别，但可以明确：只要在 session.startTransaction() 内发起的读（find、count、aggregate 等），天然就是快照读；而事务外的读（包括带 readConcern: "snapshot" 的独立操作）需要满足额外前提才能生效。
-
readConcern: "snapshot"仅对副本集主节点或分片集群的mongos有效，且要求集群开启majority读关注（writeConcern: "majority"必须启用） - 事务内无需显式设
readConcern，WiredTiger 自动保证快照一致性；事务外若手动设"snapshot"，必须确保该会话已绑定到一个活跃的 replica set 或 sharded cluster - 单节点 MongoDB 不支持
"snapshot"readConcern，会直接报错read concern 'snapshot' is not supported in standalone mode
事务必须绑定会话（session），且不能跨线程复用
MongoDB 事务生命周期完全依赖 ClientSession 对象，它承载了快照时间戳、事务状态、回滚日志上下文等关键信息。一旦 session 关闭或超时（默认 30 分钟），事务自动终止，未提交的更改全部丢弃。
常见错误是把 session 当成连接池里的共享资源反复使用：
- 多个 goroutine / thread 并发调用同一个
session的startTransaction()→ 报错Transaction numbers do not match - 在 HTTP 请求处理中复用一个全局
session实例 → 事务状态混乱，快照时间戳错乱，读到过期或不一致数据 - 忘记在
try/catch/finally或 defer 中调用session.endSession()→ 连接泄漏，后台快照长期驻留内存，WiredTiger MVCC 版本链膨胀，最终拖慢整个实例性能
正确做法是每个业务逻辑单元（如一次 API 调用）创建新 session：client.StartSession()，用完立即 endSession()，不要缓存或重用。
长事务会导致快照滞留和 oplog 增长失控
快照读的代价是 WiredTiger 必须保留旧版本数据直到所有依赖它的事务结束。如果一个事务运行超过几秒，它持有的快照会阻止后台清理机制回收历史版本，导致：
- 内存占用持续升高（
cache used指标飙升） - 磁盘空间增长异常（
dataSize和storageSize差值拉大） - oplog 回滚窗口被迫延长，影响副本集故障恢复速度
- 其他事务的快照读延迟增加（因为要遍历更长的 MVCC 链）
MongoDB 默认强制限制事务最长 60 秒（transactionLifetimeLimitSeconds），超时后自动 abort。生产环境建议主动控制在 1–3 秒内完成，尤其避免在事务中做 HTTP 调用、文件 IO、用户交互等待等外部依赖操作。
如果确实需要跨服务协调，改用 Saga 模式：拆成多个幂等子事务，用消息队列驱动状态机，而不是靠单个 MongoDB 事务兜底。
聚合管道在事务中需避开 $lookup 和 $out 等非快照安全操作
虽然 aggregate 在事务内默认走快照读，但部分 stage 会破坏一致性边界：
-
$lookup如果目标集合不在同一数据库（跨 DB），即使在事务中也会退化为非事务性读，可能读到未提交数据或触发TransactionNotActive错误 -
$out和$merge写操作虽被允许，但它们绕过事务日志双写机制，不参与原子性保障——若事务 abort，这些写入不会回滚 -
$facet或嵌套$lookup可能隐式打开多个游标，增加快照持有时间，间接放大长事务风险
安全做法是：事务内聚合只用于读取+计算，所有写操作统一收口到 session.withTransaction() 提供的回调函数里，用 collection.insertOne()、updateMany() 等原生方法执行，确保全部纳入事务日志。
快照读的高性能不是免费的，它把复杂度从「加锁阻塞」转移到「版本管理开销」上。真正压垮系统的往往不是并发量，而是某个忘了 endSession() 的 bug，或者一段在事务里 sleep(5) 的调试代码。
