MongoDB事务中“先findOne再updateOne”仍可能出错，因判断逻辑不在原子作用域内；应将条件检查与更新合并至单条updateOne的filter中，或使用带returnDocument选项的findOneAndUpdate实现原子性操作。
事务中用 findOne 检查再 updateOne 更新为什么仍可能出错
因为 findOne 和 updateOne 是两个独立操作，即使在同一个事务里，中间也可能被其他并发写入干扰——MongoDB 事务的隔离级别是「snapshot」，但只对事务内读写生效；而 findOne 返回的结果若被用于后续判断（比如“余额 > 100 才扣款”），这个判断逻辑本身不在原子作用域内。
真正安全的做法是把条件检查和更新合并进单条 updateOne 的 filter 中，让匹配与修改由服务端原子完成。
- 不要在应用层做“先查后判再更”的三步链
- 把业务规则（如
balance >= amount）直接写进updateOne的查询条件里 - 利用
updateOne的返回值（matchedCount/modifiedCount）判断是否成功执行
如何在事务中正确表达“满足条件才更新”，并获取更新前/后的值
MongoDB 不支持事务内触发器或 RETURNING 语法，但可以用 findOneAndUpdate 替代 updateOne，它在原子性基础上额外提供文档快照能力。
关键点：必须传 { returnDocument: 'before' } 或 { returnDocument: 'after' }，且该操作需在事务 session 内执行。
-
findOneAndUpdate的filter要包含全部前置条件（例如{ _id: orderId, status: 'pending', total: { $gte: 100 } }） - 更新操作（
update参数）建议用字段级更新（$set,$inc）而非全量替换，避免覆盖未参与条件的字段 - 如果需要确保“仅当未被处理过才更新”，可用
status: { $ne: 'processed' }这类否定条件，但注意$ne无法使用索引，高并发下慎用
const result = await collection.findOneAndUpdate(
{ _id: orderId, status: 'pending', balance: { $gte: amount } },
{ $inc: { balance: -amount }, $set: { status: 'deducted' } },
{ returnDocument: 'before', session }
);
if (!result.value) {
// 条件不满足：余额不足或状态已变
}
事务中嵌套条件更新失败时，matchedCount === 0 但没报错，怎么区分原因
updateOne 和 findOneAndUpdate 在条件不匹配时都静默返回 matchedCount: 0 或 value: null，不会抛异常。你得靠 filter 的设计来归因。
- 把可诊断的字段拆开：比如用
{ _id: X, version: 5 }而不是{ _id: X, $expr: { $eq: ['$version', 5] } }，前者不匹配能快速定位是数据不存在还是版本错 - 对关键业务字段加明确的状态枚举（如
status: { $in: ['pending', 'retrying'] }），避免用模糊条件如status: { $ne: 'done' } - 必要时在 filter 中加入时间窗口（
updatedAt: { $gt: new Date(Date.now() - 60 * 1000) }），防止读到陈旧锁记录
多文档条件更新在事务里为什么不能依赖 $lookup 做跨集合校验
事务内 $lookup 只支持同一分片内的集合（sharded cluster 下限制更严），且无法在 update 的 filter 阶段使用聚合管道——也就是说，你不能在 updateOne 的查询条件里写 { $expr: { $gt: [{ $size: { $lookup: ... } }, 0] } }。
跨集合的强一致性校验必须前置：要么在事务外用最终一致方式预检（接受短暂窗口），要么把相关数据冗余进主文档（如把用户信用分存到订单文档），用单文档原子更新兜底。
- 事务内唯一可行的跨集合操作是显式
collection.findOne+session，但它不提供原子性保障，只保证读取的是事务快照 - 如果业务要求“库存足够且用户信用达标”，建议把库存和信用分都冗余进订单上下文，或改用两阶段提交（2PC）模式，但复杂度陡增
- 切记：MongoDB 事务不是万能锁，它的 snapshot 隔离解决不了跨集合的竞态，设计时得主动降维
实际最难的从来不是语法，而是把业务语义准确翻译成单次原子 filter 表达式——尤其是涉及时间、状态机、数值边界混合判断时，一个括号位置错就可能漏掉并发窗口。
