mongodb事务自4.0起成为支撑真实业务的刚性能力，提供跨文档acid保障；其演进覆盖副本集到分片集群支持，关键限制包括必须绑定会话、禁止特定操作、需处理读写冲突与超时控制。
MongoDB 事务不是“锦上添花”，而是从 4.0 开始支撑真实业务落地的刚性能力——尤其当你需要跨文档保持一致性（比如扣库存+写订单+更新用户积分），又不能靠应用层重试或最终一致性兜底时，session.startTransaction() 就是唯一可行路径。
为什么单文档原子性解决不了你的问题
MongoDB 早就能保证单个 updateOne() 对一个文档的原子性，但这在复杂业务中远远不够：
- 订单创建必须同时写入
orders、inventory、user_points三个集合 - 用户注销需删掉
users、sessions、notifications多个文档，缺一不可 - 分账场景下，一笔支付要拆成多条记账流水，全部成功或全部失败
这些操作天然跨文档、跨集合，甚至跨数据库（db.getSiblingDB() 可访问其他库）。没有事务，你就得自己实现两阶段提交、补偿逻辑、幂等校验——成本远高于直接用原生事务。
4.0 到 7.0 的关键演进：从“能用”到“敢用”
事务支持不是一蹴而就的，每个大版本都在降低使用门槛和扩大适用边界：
-
4.0：仅限副本集，不支持分片集群；必须显式开启readConcern: "snapshot"和writeConcern: "majority" -
4.2：首次支持分片集群事务，但要求所有参与分片都运行 4.2+，且不能在事务中创建新集合 -
5.0：允许在事务中createCollection()和createIndex()（仅限已存在数据库） -
6.0：放宽对maxTimeMS的限制，支持更长生命周期的事务（但仍建议控制在 60 秒内） -
7.0：优化跨分片事务的提交协调开销，commitTransaction()延迟更稳定；同时增强对retryWrites: true场景下事务自动恢复的支持
注意：所有版本都不支持在事务中执行 mapReduce()、distinct()、explain() 或任何涉及临时集合的操作。
实际写法里最容易踩的三个坑
- 忘记绑定会话：事务必须通过
session执行，db.collection.updateOne()默认走无会话上下文，不会被纳入事务 - 读写冲突没处理：事务内读取的数据可能被其他会话修改，触发
WriteConflict错误；必须捕获并重试（session.abortTransaction()后重新startTransaction()） - 超时未设或设错：默认事务超时是 60 秒，但
maxTimeMS是针对单个操作的，不是整个事务；应统一用session.startTransaction({ maxCommitTimeMS: 30000 })控制整体窗口
示例片段：
const session = db.getMongo().startSession();
session.startTransaction({ readConcern: { level: "snapshot" }, writeConcern: { w: "majority" } });
try {
db.accounts.updateOne({ _id: "A" }, { $inc: { balance: -100 } }, { session });
db.accounts.updateOne({ _id: "B" }, { $inc: { balance: 100 } }, { session });
session.commitTransaction();
} catch (error) {
session.abortTransaction();
throw error;
} finally {
session.endSession();
}
事务不是万能解药，但它把 MongoDB 从“适合读多写少的松散数据”真正拉进了核心交易系统的技术选型池。真正容易被忽略的，是它对开发习惯的隐性要求：你得像写 SQL 事务一样思考——明确 begin/commit/rollback 边界，预判锁竞争点，监控 transactionMetrics 指标，而不是只把它当个语法糖。
