mongodb 6.0分片集群彻底禁用分布式事务——仅支持副本集内multi-document acid事务，向mongos发送事务请求直接报commandnotsupportedonshardedcluster错误，驱动需升级至兼容maxwireversion>=13，替代方案是重构数据模型，按分片键聚合为宽文档以保障单文档原子性。
MongoDB 4.0 迁移到 6.0 后，分布式事务在分片集群中基本不可用——这不是配置问题，而是架构限制被进一步收紧。
分片集群下 multi-document 事务已明确不支持
从 4.0 开始，MongoDB 就只允许在副本集（replica set）内执行跨文档 ACID 事务；到了 6.0，这一限制不仅没放松，反而在文档和错误行为上更严格：
- 向分片集群的
mongos发送带session.startTransaction()的请求，会直接返回CommandNotSupportedOnShardedCluster错误，不再静默降级或尝试执行 -
db.adminCommand({ "listTransactions": 1 })在分片环境下始终为空，即使你手动绕过驱动、用 raw BSON 提交事务命令，mongos也会在协议层拦截 - 聚合管道中的
$lookup阶段若跨分片引用集合，即使不显式开启事务，也可能因内部快照一致性机制触发隐式事务检查，导致整个 pipeline 失败并报TransactionNumbersMismatch
驱动层事务 API 调用会静默失败或抛出新异常
老版本驱动（如 Node.js Driver 4.x、Java Driver 3.12）在连接 6.0+ 分片集群时，调用 withTransaction() 不再返回超时或空结果，而是明确抛出 MongoServerSelectionError 或 MongoInvalidArgumentError，原因不是连接失败，而是服务端拒绝协商事务上下文：
- Python
pymongo 3.12会在session.start_transaction()时收到OperationFailure: This command is not supported on sharded clusters - Spring Data MongoDB
3.3.x默认启用事务代理，若未显式禁用（如@Transactional(propagation = Propagation.NOT_SUPPORTED)），启动时即报TransactionNotSupportedException - 所有驱动在 6.0+ 下都要求
maxWireVersion >= 13，否则直接拒绝建立事务会话——这意味着你必须升级驱动，且旧驱动即使连得上，事务调用也必然失败
替代方案不是“换语法”，而是重构数据边界
不能依赖“事务兜底”，就得把原来靠事务保证一致性的逻辑，拆到单一分片键可覆盖的范围内。常见踩坑点包括：
- 误以为加
shardKey: { userId: 1 }就能对user和user_orders做原子更新——实际仍需确保两集合使用完全相同的分片键定义 + 相同的分片策略，否则$lookup仍跨片，事务无意义 - 用
findAndModify替代事务更新时，忽略其仅保证单文档原子性：若业务需“扣库存 + 写订单 + 记日志”三步，仍可能在第二步失败后留下脏状态 - 试图用 change stream + 补偿任务模拟事务，但未处理
resumeToken断连重续场景，导致补偿漏触发——6.0 中 change stream v1 恢复令牌与事务日志深度强绑定，非事务操作也可能影响 token 连续性
真正要动的是数据模型：把原本松散关联的文档，按业务聚合边界预合并为宽文档（如把用户、地址、最近 5 笔订单存进一个 user_profile 集合），让关键操作回归单文档原子性。这不是退化，而是适配分片本质——6.0 没给新能力，只是把旧规则写得更死。你绕不开，只能重划边界。
