MongoDB事务不保证外键一致性，仅提供多文档原子性；外键引用需手动校验，聚合更新可规避并发竞态但无法替代事务的跨集合补偿场景。
MongoDB 事务不能保证外键引用一致性
MongoDB 原生不支持外键约束，所谓“事务解决外键一致性”是常见误解。事务只保证多文档写入的原子性（session.startTransaction() 内的操作要么全成功、要么全回滚），但不会自动校验 user_id 是否真实存在于 users 集合中——这仍需你手动查、手动判、手动抛错。
典型错误场景：在事务里先插入一条 orders 文档，引用了尚未提交的 users 文档（或根本不存在的 user_id），事务照样提交成功。因为 MongoDB 不做引用完整性检查。
- 事务内
db.users.findOne({ _id: orderId.userId })必须显式调用，且要处理null结果 - 如果被引用文档在另一事务中正被删除或修改，还需考虑读隔离级别（
readConcern: "snapshot"可缓解，但不治本） - 跨集合查询在事务中性能下降明显，尤其涉及大集合时，
explain()显示executionTimeMillis往往翻倍
用多文档更新替代客户端校验的适用边界
所谓“多文档关联更新”，本质是把原本分散在应用层的 find + validate + update 三步，压进一个 updateMany() 或聚合管道更新（updateOne(..., { pipeline: [...] })）中，在服务端完成条件判断和变更。它不依赖事务，也不需要多次往返。
适合场景：状态流转类操作，比如“把用户所有待支付订单改为已取消”，且订单状态字段与用户状态强相关（如用户被禁用 → 其订单不可再支付）。
- 必须能用
$lookup在聚合更新中关联另一集合（4.2+ 支持from为其他集合） - 被关联集合（如
users）需在关联字段（如_id）上有索引，否则$lookup会全表扫描 - 聚合更新不支持对被
$lookup的集合做写操作，只能读；真正写入仍发生在主集合上 - 错误示例：
db.orders.updateMany({ status: "pending" }, [ { $lookup: { from: "users", localField: "user_id", foreignField: "_id", as: "u" } }, { $set: { status: { $cond: { if: { $eq: ["$u.status", "active"] }, then: "pending", else: "canceled" } } } } ])—— 这里$u.status是数组，需用{ $arrayElemAt: ["$u.status", 0] }提取
为什么不用客户端校验而选服务端聚合更新
客户端校验（先查用户状态，再决定是否更新订单）在并发下必然出现竞态：A 读到用户状态为 active，B 同时将用户禁用，A 还按旧状态执行了订单更新。这是分布式系统中最难压测出又最常发生的逻辑漏洞。
聚合更新把“读状态 + 判条件 + 写结果”锁在单次数据库请求内，天然规避该问题。但它不是银弹：
- 无法触发应用层业务钩子（如发通知、调外部 API），这些仍得靠应用监听变更流（
change stream）补全 - 错误反馈弱：失败时只返回匹配数为 0，无法直接知道是用户不存在、还是状态不匹配——需额外加
$facet或分两步查 - 调试困难：
db.orders.aggregate([...]).toArray()和db.orders.updateMany(..., { pipeline: [...] })行为不完全等价（后者不支持$merge等阶段）
真正需要事务的时刻：跨集合的补偿型操作
当业务要求“用户退款成功 → 订单状态变已退款 → 库存数量加回”，且三者缺一不可时，才必须用事务。此时不是为外键一致性，而是为业务最终一致性兜底。
关键实操点：
- 所有操作必须在同一个
session中，且使用withTransaction()封装，不要裸写startTransaction() -
users、orders、inventory三个集合的关联字段（如user_id,order_id）必须全部建索引，否则事务可能因慢查询被中断 - 避免在事务中调用
sleep()或长时间计算；MongoDB 事务默认最大运行时间 60 秒，超时自动 abort - 网络分区时，客户端可能收不到 commit 响应，但服务端已提交——必须实现幂等重试（用唯一
transaction_id字段去重）
外键一致性终究是语义层问题，数据库只管原子性。设计时得想清楚：那个 user_id 字段，到底承载的是“存在性承诺”，还是仅作“标记用途”。后者连聚合更新都不必上，前者才值得投入事务和索引成本。
