事务仅适用于有跨文档强一致性需求的场景，如银行转账；若只需最终一致，应优先选用单文档原子操作、两阶段标记或应用层补偿等轻量方案。
事务不是开关，是权衡：先看业务有没有「跨文档强一致性」需求
MongoDB 从 4.0 开始支持副本集事务，4.2 起支持分片集群事务，但启用事务不等于应该用事务。核心判断标准只有一个：业务逻辑是否要求多个文档的修改必须全部成功或全部失败，且中间状态不能被其他读操作看到。比如银行转账、库存扣减+订单创建+日志写入三者必须原子性完成——这种才是真需求。如果只是「尽量一致」或「最终一致就够了」，比如用户发帖后更新个人动态计数，用 $inc 或事件驱动更轻量。
常见误判场景：
• 把「防止重复提交」当成事务需求（实际该用幂等 key 或唯一索引）
• 把「多步写入顺序」当成事务需求（实际靠应用层串行或队列就能控序）
• 看到「要改两个 collection」就默认要事务（其实多数情况用两阶段提交模拟或最终一致性更稳）
查查你的读写模式：事务会锁住整个写入路径
MongoDB 事务在执行期间会对所有涉及的文档加写锁（WiredTiger 引擎下是文档级），且事务内所有操作共享同一个快照。这意味着：
• 长事务会阻塞其他写操作，尤其当事务里有慢查询（如未命中索引的 find()）或大范围更新（如 updateMany({ status: "pending" }, { $set: { processed: true } })）
• 事务内读操作看不到其他并发写入的新数据（快照隔离），可能造成业务逻辑错觉
• 分片集群下事务跨分片时，协调成本高，超时默认 60 秒（maxTransactionTimeMillis 可调，但不建议盲目拉长）
实操建议：
• 在测试环境用真实流量压测事务路径，观察 currentOp 中的 secs_running 和锁等待时间
• 避免在事务里做 HTTP 请求、文件读写、复杂计算等外部依赖
• 如果必须查大量数据再写，优先把读提到事务外，只把「确定要改的文档 ID 列表」传进事务
对照 MongoDB 版本和部署形态：不是所有环境都支持事务
事务功能有硬性前提，漏掉一个就直接报错：
• 必须是 WiredTiger 存储引擎（MMAPv1 已废弃且不支持）
• 副本集模式下需 majority 写关注（w: "majority"），否则 abortTransaction 可能失败
• 分片集群要求所有分片和 config server 都是 4.2+，且开启 featureCompatibilityVersion: "4.2"（升级后必须手动设置）
• Serverless（Atlas Free Tier）和某些托管服务（如早期阿里云 MongoDB 版）默认关闭事务支持
验证方式很简单：
• 连上数据库执行 db.runCommand({ serverStatus: 1 }).storageEngine.name 确认是 WiredTiger
• 查 rs.conf() 里的 protocolVersion 是否为 1
• 尝试启动空事务：session = db.getMongo().startSession(); session.startTransaction(); session.abortTransaction();，报错则说明环境不满足
替代方案往往更简单：先试试这些再上事务
90% 的所谓「需要事务」场景，其实有更轻、更稳、更易维护的解法：
• 单文档原子操作：用 findAndModify() 或带 $setOnInsert 的 upsert 处理「查-改」逻辑
• 两阶段标记：比如订单先写 status: "creating"，成功后再 $set status: "created"，后台定时任务兜底
• 应用层补偿：记录操作日志（如 Kafka），失败时触发逆向动作，比分布式事务更容易监控和重试
• 唯一索引防重：代替事务做「存在性校验」，例如用 { userId: 1, orderId: 1 } 复合唯一索引防重复下单
真正值得上事务的信号很窄：
• 涉及 3+ 个文档的写入，且任意一步失败都会导致业务状态不可恢复
• 对账、财务类场景，审计要求强一致性证据链
• 已经用尽所有单文档/补偿手段，仍频繁出现数据漂移且无法接受
事务不是银弹，它把一致性保障从应用层推给数据库，但代价是锁、延迟和运维复杂度。上线前多问一句：这个一致性，用户真的会在意吗？还是只是我们怕出错？
