mongodb 4.0 仅支持副本集内多文档事务，不支持分片集群；4.2 才真正实现跨分片 acid，需满足 wiredtiger 引擎、4.2+ 全节点版本、fcv 设为 4.2、config server 在线等四项硬性条件。
MongoDB 4.0 不支持分片集群事务，4.2 才真正实现跨分片 ACID —— 这不是配置问题，是架构级限制。
4.0 只能在副本集内开启事务，standalone 或 sharded cluster 直接报错
常见错误现象包括：Transaction numbers are only allowed on a replica set（启动 startTransaction() 时连接的是单机或 mongos）、Transaction is not supported on sharded clusters（在 4.0 的分片集群上误调用事务 API）。
实操建议：
- 确认部署模式：执行
rs.status()，必须返回至少 3 个成员（含primary），且isMaster.hosts非空；sh.status()必须报错或无输出，否则说明已启用分片 - 连接字符串必须显式带
?replicaSet=xxx，不能指向mongos地址（如mongodb://host1:4000） - 事务生命周期严格绑定
session，所有操作必须通过session.getDatabase(...).collection执行，混用普通db.collection会静默脱离事务上下文
4.2 分片事务需满足 4 项硬性条件，缺一不可
不是升级到 4.2 就自动可用。分片事务依赖两阶段提交（2PC），涉及 config server 协调，失败风险和性能代价显著上升。
必须同时满足：
- 所有 shard、config server、mongos 均运行 MongoDB 4.2+，且执行
db.adminCommand({setFeatureCompatibilityVersion: "4.2"}) - 全部节点使用
WiredTiger引擎（MMAPv1已被弃用，无法启用事务） - config server 必须可写且在线；若它宕机，新事务无法开启，进行中的事务可能卡在
prepare状态 - 客户端驱动版本 ≥ 3.11（Java）、≥ 3.12（Python），旧驱动会静默降级为非事务行为
事务行为差异：超时、大小、冲突处理、读可见性
表面 API 一致（startTransaction()/commitTransaction()），但底层约束完全不同。
关键区别点：
-
transactionLifetimeLimitSeconds默认仍是 60 秒，但 4.2 允许通过maxTimeMS单独控制每条操作时限，不延长总生命周期 - 4.0 事务所有写入打包进单条 oplog，硬性限制总大小 ≤ 16MB；4.2 支持多条 oplog（每条 ≤ 16MB），取消该限制
- 写冲突时均抛
WriteConflict，需应用层捕获并重试 —— MongoDB 从不自动重试事务 - 分片事务中，
readConcern: "local"下外部读可能只看到部分分片的写入结果（如分片 A 已提交，B 还未同步），不保证全局强一致性
别忽略建模优先原则：多数场景根本不需要跨分片事务
事务是兜底手段，不是设计起点。MongoDB 文档模型天然适合嵌套聚合，比如把订单 + 订单项存为单文档，用 updateOne() 原子更新整个结构 —— 这比跨集合事务快一个数量级，也更可靠。
真正需要分布式事务的场景极少：金融记账、库存与履约强耦合、跨业务域对账等。其他情况，优先考虑最终一致性 + 补偿逻辑，或调整分片键让相关数据落在同一分片内。
