不能直接用 session.withTransaction()，因为Express请求与MongoDB会话生命周期不自动对齐，需手动管理session创建、传递、错误重试及endSession()；转账须用带余额校验条件的updateOne确保原子性。
为什么不能直接用 session.withTransaction() 就完事？
因为 Express 的请求生命周期和 MongoDB 事务的会话（ClientSession）生命周期不自动对齐：事务必须在同一个 ClientSession 中完成所有操作，且该会话需显式结束（endSession() 或自动超时）。如果在中间件里创建 session 却没传给后续路由，或异步操作中丢失了 session 引用，就会报 Transaction numbers do not match 或 no transaction started。
实操建议：
- 在路由入口处调用
client.startSession()，不要复用全局 session - 把 session 作为参数显式传入业务函数，避免闭包捕获或中间件“注入”导致的引用混乱
- 必须用
try/catch/finally包裹事务体，finally中调用session.endSession() - 别在事务内调用其他未接入同一 session 的 Model 方法——Mongoose 默认不继承 session，得手动传
{ session }
转账逻辑里怎么安全地查+改两个账户？
MongoDB 事务要求所有读写操作都发生在同一数据库（或同一分片集群的数据库），且集合必须是副本集或分片集群。批量转账本质是多文档更新，但事务内不能靠两次 findOneAndUpdate 硬凑，容易因并发导致余额错乱。
实操建议：
- 先用
collection.findOne({ _id: accountId }, { session })查出当前余额，校验是否足够（注意：此时读取的是事务快照，不会被外部修改干扰） - 再用
collection.updateOne({ _id: accountId }, { $inc: { balance: -amount } }, { session })扣款 - 同理对收款方做
$inc: { balance: +amount }，不要用save()或updateMany()—— 后者可能误触其他文档 - 所有操作必须带
{ session }选项，Mongoose 的doc.save({ session })也有效，但不如原生 update 明确
如何处理部分失败时的回滚与错误透传？
事务内任意操作失败（如校验不通过、唯一索引冲突、网络中断），只要没显式 commitTransaction()，MongoDB 会自动丢弃所有变更。但 Express 需要正确响应客户端：不能让前端以为成功，也不能把底层 WriteConflict 这类重试型错误直接暴露给用户。
实操建议：
- 在
catch块里检查错误码：error.hasErrorLabel("TransientTransactionError")表示可重试，应主动重试整个事务（最多 1–2 次） - 如果是业务错误（如 “余额不足”），抛出自定义错误（如
new Error("INSUFFICIENT_BALANCE")），并在 Express 错误中间件中映射为 400 - 别在事务函数里
res.json()—— 应统一由外层路由控制响应，否则session.endSession()可能被跳过 - 记录日志时带上
session.id，方便追踪某次转账的完整数据库操作链
并发转账时为什么还会出现超扣？
即使用了事务，如果多个请求同时读取同一账户余额（比如都读到 100 元），再各自扣 60 元，就可能变成 -20 元。这不是事务失效，而是应用层没做“读已提交+条件更新”的组合防护。
实操建议：
- 在扣款
updateOne时加上余额校验条件：{ $and: [{ _id: accountId }, { balance: { $gte: amount } }] } - 检查
result.matchedCount === 1 && result.modifiedCount === 1，否则说明余额不足或已被他人修改，应终止事务并返回错误 - 避免在事务外做“先查后判再更”的三步操作——这中间有竞态窗口，必须压缩进单条带条件的 update
- 高并发场景下，考虑按账户 ID 分片路由请求，或引入 Redis 分布式锁（仅限极端情况，多数时候条件 update 已足够）
