MongoDB 4.2 以下分片集群不支持事务，因服务端未实现跨分片两阶段提交协议，4.1 及更早版本在 mongos 上调用 startTransaction() 直接报错。
为什么 MongoDB 4.2 以下分片集群根本没法开事务
MongoDB 在 4.2 才首次为分片集群（sharded cluster）加入分布式事务支持。4.1 及更早版本的 session.startTransaction() 在分片环境下直接报错：Transaction numbers are only allowed on a replica set member or a mongos —— 这不是配置问题，是服务端压根没实现跨分片的两阶段提交协议。
你哪怕把所有分片都升级成副本集、开了 enableMajorityReadConcern，只要 mongos 版本
- 4.0 分片集群只支持「单文档写入的原子性」，
updateOne或deleteOne是安全的，但updateMany不保证全部成功或全部失败 - 事务回滚、会话保持、跨库跨集合操作，在 4.2 前的
mongos层连解析都做不到，直接拒绝请求 - 别信“加个
readConcern: "majority"就能模拟”，它只管读一致性，不提供写事务语义
绕过限制：用应用层补偿 + 幂等设计扛住多步写入
既然数据库层不给事务，就得在代码里自己兜底。核心思路不是“模拟 ACID”，而是“让失败可恢复、重试不翻车”。
典型场景比如：扣库存 + 写订单 + 发通知，三步必须全成或全退。不能靠 try/catch 包住就完事——网络超时、进程崩溃、中间步骤成功后卡住，都会留下脏数据。
- 每一步操作前先写一条状态记录到专用集合（如
transaction_log），包含唯一tx_id、步骤名、输入参数、时间戳 - 所有业务写操作必须带幂等键，例如订单号、库存扣减请求 ID，重复执行
updateOne({ orderId: "xxx" }, ..., { upsert: true })不会产生副作用 - 失败后触发异步补偿任务，按
tx_id查日志，从第一个未完成步骤重试；已成功的跳过，避免双扣、双发 - 别用内存变量存中间状态——进程重启就丢，必须落库
哪些操作其实根本不需要事务，却被误当成痛点
很多团队喊“没事务没法做 XX”，结果拆解发现只是没想清数据模型或读写模式。
例如用户积分变更：以为要“查余额 → 判定是否足够 → 扣减 → 记流水”四步串行，非得事务保一致。其实用原子操作就能解决：
db.users.updateOne(
{ _id: userId, points: { $gte: amount } },
{ $inc: { points: -amount } }
)
这个操作天然满足“余额不足则整条失败”，不需要事务参与。类似地：
-
findAndModify/findOneAndUpdate的原子条件更新，覆盖 70%+ 的“先读后写”场景 - 计数类字段用
$inc，状态流转用$set配合$in条件，避免读-改-写三段式 - “写 A 同时写 B”如果 B 只是 A 的衍生视图（比如统计汇总），完全可以异步跑批，不强求实时一致
升级到 4.2+ 的真实门槛和替代路径
升级不是改个配置就行。分片集群升级必须满足：所有分片副本集 ≥ 4.2、config server ≥ 4.2、mongos ≥ 4.2，且整个过程要求停写窗口或灰度切流。
如果暂时升不了，比补偿逻辑更轻量的方案是：把强事务需求收敛到单一分片上。
- 用哈希分片（
sh.shardCollection("db.collection", { _id: "hashed" })）配合客户端预计算_id，确保关联数据落到同一分片 - 在该分片内用副本集连接直连（绕过
mongos），此时 3.6+ 就支持单副本集事务 - 代价是牺牲部分水平扩展能力——该集合不能再靠分片扩容，但换来的是最简路径落地事务语义
真正卡住的往往不是技术方案，而是对“事务必要性”的误判：把最终一致性场景当成了强一致性刚需，或者把本该由消息队列解耦的流程硬塞进一次数据库调用里。
