MongoDB事务仅适用于单分片或副本集部署，跨分片不支持；订单状态更新多为幂等单文档操作，无需事务；仅当需原子性保障多文档协同变更（如扣库存+改订单+写日志）且同副本集同库时才启用。
MongoDB 事务在电商订单系统中**仅适用于单分片（single shard）或副本集（replica set）部署下的强一致性场景**，跨分片事务不被支持，且开启事务会显著降低吞吐量。如果你的订单系统已分片、QPS 超过 5000、或使用了 mongos 路由层，直接套用事务反而会引入延迟和锁竞争，得不偿失。
订单状态流转必须用事务吗？
不是必须。大多数订单状态更新（如 pending → paid → shipped）本身是幂等、单文档操作，用 updateOne() 配合 $set 和 $inc 就够了。事务真正必要的场景只有一个：**需要原子性保障的多文档协同变更**，比如“扣库存 + 改订单状态 + 写日志”三者必须全成功或全失败。
- 典型误用：只为改一个订单的
status字段开事务——纯属浪费资源 - 合理用法：用户下单时，同时更新
orders集合中的订单文档、inventory集合中对应 SKU 的可用库存、order_logs集合写一条审计记录 - 注意：这三个集合必须在同一个 replica set 中；若
inventory已按仓区分片（如inventory_shanghai、inventory_beijing），就无法纳入同一事务
库存扣减为什么不能只靠 $inc？
$inc 确实能避免读-改-写竞态，但无法防止超卖。比如库存只剩 1，两个并发请求同时读到 stock: 1，都执行 $inc: {available: -1}，结果变成 -1。解决办法是加条件判断：
db.inventory.updateOne(
{ _id: "SKU12345", available: { $gte: 1 } },
{ $inc: { available: -1 } }
)
这个操作返回 matchedCount：为 0 表示库存不足，无需事务；为 1 才继续后续步骤。但如果后续还要写日志、发消息、更新订单，而这些又不能回滚，那才需要把整个链路包进事务。
- 关键点：
$inc+ 条件匹配 是无事务方案的底线，90% 的库存扣减应优先走这条路 - 事务方案只在业务要求“库存扣减失败时，订单创建也必须彻底回滚（包括已生成的订单号）”时启用
- MongoDB 事务不支持跨数据库操作，所以
orders和inventory必须在同一个数据库内
Spring Data MongoDB 中开启事务的硬性前提
Spring Boot 项目里用 @Transactional 注解对 MongoDB 生效，前提是：必须使用 ReactiveMongoTransactionManager（响应式）或 MongoTransactionManager（阻塞式），且底层 MongoClient 连接的是 replica set，不是 standalone 或 mongos。
- 常见错误：application.yml 中配置了
spring.data.mongodb.uri=mongodb://localhost:27017，但本地启动的是单节点模式——事务会静默失效，不报错也不生效 - 验证方法：连接后执行
db.runCommand({isMaster: 1})，确认返回中有"ismaster": true且"hosts"数组长度 ≥ 3（即副本集） - Java 示例中必须显式获取
ClientSession，不能依赖 Spring 自动注入的MongoTemplate默认行为
真正棘手的不是语法怎么写，而是判断“这里到底需不需要事务”。电商系统里，订单号生成、优惠券核销、积分变动、物流单号分配……每个环节都有自己的幂等机制和补偿逻辑。把它们一股脑塞进 MongoDB 事务，等于放弃水平扩展能力，也掩盖了分布式系统本该直面的问题：网络分区、服务降级、最终一致性设计。事务是兜底手段，不是默认选项。
