升级MongoDB 4.0前必须确认：①部署为副本集或分片集群，单机不支持事务；②存储引擎必须为WiredTiger；③所有事务集合须预先创建，驱动版本需达标。
升级前必须确认的三个兼容性前提
MongoDB 4.0 引入多文档事务，但不是所有部署都能直接用。事务只在 replica set 或 sharded cluster 上可用，单节点 standalone 模式不支持。你如果还在用单机开发环境，mongod --replSet rs0 启动并初始化副本集是硬性前置步骤。
- 必须使用 WiredTiger 存储引擎（
storage.engine配置为wiredTiger），MMAPv1 已被弃用且不支持事务 - 所有参与事务的集合必须已建好（不能在事务里执行
db.createCollection()） - 客户端驱动版本需 ≥ 对应语言的最低要求：Node.js 需
mongodb@3.2.0+，Python 需pymongo@3.8.0+
检查当前配置：运行 db.serverStatus().storageEngine.name 和 rs.status().members，确认返回 wiredTiger 和至少 3 个健康成员（或 1 主 2 副本的最小可用集）。
模型字段变更如何与事务逻辑解耦
事务本身不改变 Schema，但升级模型时容易误把“字段加减”塞进事务块——这是典型误区。事务只保证操作原子性，不负责迁移数据。比如你要给 users 集合加 last_login_at 字段，正确做法是：
- 先停写或切读写流量（视业务容忍度）
- 用
db.users.updateMany({}, {$set: {last_login_at: null}})批量补默认值（注意：该操作不在事务内） - 应用层代码上线新逻辑，后续写入由应用控制赋值
- 若需强一致性补全（如补历史登录时间），再用事务包装单条更新，例如：
session.startTransaction(); db.users.updateOne({ _id: ObjectId("...") }, { $set: { last_login_at: new Date() } }, { session }); db.logins.insertOne({ user_id: "...", at: new Date() }, { session }); session.commitTransaction();
关键点：Schema 变更和事务逻辑是两层事，混在一起会导致事务超时、锁表时间不可控。
事务超时与锁行为的实际影响
MongoDB 4.0 默认事务超时是 60 秒（transactionLifetimeLimitSeconds 参数可调），但更隐蔽的问题是写锁粒度。事务中任意一个写操作会持有文档级锁，若事务内包含多个 updateOne 跨不同分片键（sharded 环境）或大量匹配文档（如 updateMany），可能触发锁等待甚至死锁。
- 避免在事务中使用无索引字段做查询条件（会扫描全集合，锁住更多文档）
- 不要在事务里调用外部 HTTP 接口或长时间计算——超时后自动 abort，但已写的文档不会回滚（WiredTiger 的事务日志不覆盖非事务操作）
- 分片集群下，确保所有操作落在同一分片（即共享相同
shard key），否则事务会失败并报错Multi-document transactions in sharded clusters require all operations to be on the same shard
如果你的应用习惯用“查→算→改”三步，升级后得重构成“查（带 session）→ 改（带 session）”，中间不能穿插非事务操作。
降级风险与回滚边界在哪里
MongoDB 不支持“版本回退”：从 4.0 降级到 3.6 会导致数据文件不可读，因为 4.0 的 WiredTiger 元数据格式已变更。所谓“平滑升级”，本质是单向演进。
- 备份必须在升级前完成，且验证能恢复（用
mongorestore --noIndexRestore测试还原速度） - 如果用了 4.0 新增的
$lookup+let+pipeline语法，降级后查询直接报错unrecognized field 'let' - 最容易被忽略的是驱动层：即使服务端没升级，只要应用用了
withTransaction()方法，老版本驱动会静默忽略事务上下文，变成普通非事务操作——表面跑通，实则丢失一致性
别指望靠“先试小流量再全量”来兜底事务逻辑，事务的原子性和隔离性一旦缺失，错误是静默且难追溯的。
