node.js中mongodb事务需满足三个硬性前提：必须运行在副本集或分片集群上，单机模式不支持；必须调用client.startsession()创建会话且在connect后执行；必须使用withtransaction()并显式传入{session}选项，所有操作均需绑定该会话。
Node.js 中 MongoDB 事务不是“开了就能用”的功能，它依赖服务端环境、驱动调用顺序和会话生命周期三个硬性前提。缺一不可，否则直接报错或静默失败。
事务必须在副本集里运行，单机 mongod 不行
MongoDB 服务端强制要求：事务只能在副本集（replica set）或分片集群中执行。本地开发时如果只起 mongod --port 27017，哪怕驱动版本再新、代码写得再标准，也会立刻失败，错误信息是：Transaction numbers are only allowed on a replica set member or mongos。
- 最轻量的修复方式是启动时加
--replSet rs0参数：mongod --replSet rs0 --port 27017 --dbpath /data/db - 然后连上 shell 执行
rs.initiate()，等状态变成"stateStr" : "PRIMARY"再跑事务代码 - 不要试图用 Docker Compose 拉一个单节点容器就开事务——它不满足副本集拓扑，照样报错
client.startSession() 是强制前置步骤，不能省略
所有事务操作都必须基于一个显式创建的 session 对象。漏掉这一步，后续任何 withTransaction() 或手动 commitTransaction() 都会抛出 TypeError: Cannot read property 'startTransaction' of undefined 或 TopologyDescription not connected。
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
-
session = client.startSession()必须在await client.connect()之后调用，否则 session 内部没绑定连接 - 每个事务必须用独立的
session：一次withTransaction()结束后，该session就失效了，不能再复用；要再开事务，必须先session.endSession()，再client.startSession() - 别把
session当成全局变量缓存——它带状态、有生命周期，跨请求复用会导致竞态和连接泄漏
用 withTransaction() 而不是手动 commit/abort
手动控制 session.commitTransaction() 和 session.abortTransaction() 极易出错：Promise rejection 未被捕获、异步逻辑分支遗漏、异常堆栈中断都会导致事务卡住，MongoDB 日志里反复出现 transaction is already committed or aborted 这类误导性提示。
-
withTransaction()自动包裹 try/catch，任何throw、Promise.reject()或未处理的 rejected promise 都触发 abort - 回调函数必须返回 Promise（即用
async () => { ... }），否则事务不会等待内部操作完成就直接 commit - 回调里禁止再调
session.commitTransaction()—— 会报Transaction already completed - 它还内置重试逻辑（默认 5 次），对临时网络抖动或写冲突更鲁棒
所有操作都得显式传 { session }，不能只靠闭包
事务不是“开启 session 后自动生效”的上下文机制。每个涉及数据变更的操作（insertOne、updateOne、deleteMany 等）都必须显式传入 { session } 选项，否则操作脱离事务边界，变成普通写入。
- 常见错误：在
withTransaction()回调里调用db.collection('x').insertOne({...})，漏掉{ session }，结果日志里看到数据被插进去了，但事务回滚时它还在 - 读操作也建议加
readConcern: 'majority'，否则可能读到未提交中间态（尤其在因果一致性场景下） - 事务内不能跨数据库操作：所有集合必须属于同一个
db实例，client.db('a').collection('x')和client.db('b').collection('y')无法放在同一事务中
最容易被忽略的是：事务不是万能锁。它解决的是多文档原子性，但无法替代应用层幂等设计、唯一索引或前端防重提交。比如用户双击转账按钮，即使事务成功，也可能因两次请求各自开启独立事务，造成重复扣款——这时候得靠订单号唯一索引 + 接口幂等 key 来兜底。
