$lookup 在事务中无法保证跨文档一致性快照，因其读取右表时使用最终一致视图而非事务MVCC快照；替代方案包括嵌入关键字段、双读显式获取快照或$facet分步读取并拼装。
$lookup 不能在事务中保证跨文档一致性快照——它查到的右表数据，可能比事务开始时已提交的最新状态还旧几毫秒，这不是 bug，是 MongoDB 的模型限制。
为什么事务里用 $lookup 仍会读到“过期”数据
事务只保证自身写入的原子性和隔离性，但 $lookup 是聚合阶段，它不参与事务的快照读机制。即使整个聚合管道跑在 session.startTransaction() 内，$lookup 去拉 from 集合时，用的是当前时间点的“最终一致视图”，而非事务开启那一刻的 MVCC 快照。
- 右集合（如
users）正在被其他客户端并发更新，$lookup可能读到更新前的旧值 - 事务内先
$set了订单状态，再$lookup关联用户信息，但用户信息仍是事务外上次写入的结果 - 分片集群下更明显：跨分片
$lookup甚至不保证所有分片读取时间点对齐
替代方案：用事务 + 嵌入或双读规避关联时差
想让关联结果和事务状态严格一致，必须绕开 $lookup 的实时拉取行为：
- 把关键关联字段（如
user.status、user.email）冗余嵌入主文档（如orders），事务内一并更新，读时直接取，无延迟 - 事务内先
findOne读出关联文档（如db.users.findOne({ _id: orderId.userId })），再用该快照值参与后续逻辑判断或$set - 若必须用聚合，改用
$facet分别读左/右集合，再$mergeObjects拼装——但注意：两个$facet子管道仍各自走最终一致，只是把“不一致窗口”显式暴露给你控制
如果非用 $lookup 不可，至少加时间兜底过滤
无法彻底消除不一致，但可以压缩其影响窗口。在 $lookup 的 pipeline 中强制加 $match 过滤“太老”的数据：
{
$lookup: {
from: "users",
localField: "user_id",
as: "u",
pipeline: [
{ $match: { updatedAt: { $gt: { $subtract: ["$$NOW", 5000] } } } }
]
}
}
-
$$NOW是聚合执行时刻的时间戳，不是事务开启时间，但比无过滤强得多 - 5000 毫秒是经验值，需根据业务容忍度和写入频率调整；设太小会导致关联数组为空（
[]） - 确保
users.updatedAt字段有索引，否则$match无效，照样全表扫
真正难处理的不是语法怎么写，而是接受一个事实：$lookup 和事务本就不属同一抽象层。想靠它获得 ACID 级别的一致性，就像用 SELECT FOR UPDATE 去锁 Redis 数据一样，方向错了。
