MongoDB事务不支持外键和级联删除，必须手动在事务中按依赖顺序显式删除关联文档，所有操作需在同一session内完成且关联字段须建索引。
MongoDB 事务里不能直接声明外键，级联删除得手动写
MongoDB 本身不支持外键约束，也没有 ON DELETE CASCADE 这类语法。事务只是保证多文档操作的原子性，但“哪些文档该删”“删到哪一层”完全由你决定。这意味着：级联逻辑必须显式编码，不能靠数据库自动推导。
常见错误是以为开启事务后调用 deleteOne() 就会自动清理关联数据——实际上它只删当前集合里的匹配文档，其他集合一动不动。
- 必须在事务内显式调用多次
deleteMany()或updateMany()，分别处理每个关联集合 - 所有涉及的集合必须属于同一个分片（shard）或副本集（replica set），跨分片事务不支持
- 事务生命周期内不能执行读取未提交数据的操作（如带
readConcern: "local"的查询），否则可能读到中间态
怎么安全实现“用户删除 → 清理其订单 + 地址”这类级联
核心是把关联关系建模成可查、可索引的字段，并在事务中按依赖顺序操作。比如用户集合 users 和订单集合 orders 之间靠 userId 关联，那就要确保 orders.userId 有索引，否则 deleteMany({ userId: "u123" }) 会全表扫描，事务超时风险高。
实操建议：
- 先查出待删用户的完整 ID（避免用用户名等非唯一字段做条件）
- 在事务中按“被依赖方 → 依赖方”顺序删除：先删
orders，再删addresses，最后删users文档本身 - 每步都检查
result.deletedCount，若为 0 可提前终止事务，避免误删主文档后发现子数据根本不存在 - 用
session.withTransaction()包裹整个流程，别漏掉session参数传给每个deleteMany()
示例关键片段：
await session.withTransaction(async () => {
await db.collection("orders").deleteMany({ userId: userId }, { session });
await db.collection("addresses").deleteMany({ userId: userId }, { session });
await db.collection("users").deleteOne({ _id: userId }, { session });
});
为什么不能用 $lookup 模拟级联？它不参与事务写操作
$lookup 是聚合阶段，只用于查询时“拼数据”，对文档无任何修改能力。有人试图在事务里跑一个带 $lookup 的聚合，再根据结果去删——这不行：事务外的聚合结果无法保证原子性，且 $lookup 返回的数据可能在事务提交前就被其他写操作改掉。
更危险的是，在事务中执行 find() 获取待删 ID 列表，然后跳出事务去删——这彻底失去原子性，中间任何失败都会导致数据不一致。
- 所有读取和写入必须在同一
session内完成 - 如果关联数据量大（比如用户有上万条订单），考虑分批删除，但每批都得在同一个事务里完成，否则无法回滚
- 不要依赖应用层缓存的关联 ID 列表，每次都应实时查（在事务内）
真正要注意的坑：事务超时和锁竞争
MongoDB 默认事务最大运行时间是 60 秒，一旦级联涉及多个大集合或慢查询，很容易触发 MaxTimeMSExpired 错误。这不是代码写错了，而是设计没压住资源消耗。
- 所有被删集合的关联字段（如
userId）必须建好索引，否则deleteMany()会变慢甚至阻塞 - 避免在高并发场景下对同一用户反复执行级联删除——事务会持有写锁，阻塞其他对该用户相关集合的写入
- 如果业务允许弱一致性（比如订单归档后才删），可考虑用后台任务异步清理，而非强事务保障
最常被忽略的一点：事务内不能调用其他数据库连接或外部 HTTP 请求。所有逻辑必须收束在单个 session 的 MongoDB 操作里，否则既不安全也不可控。
