MongoDB事务不保证跨文档/跨集合访问顺序，死锁风险源于应用层资源争抢；必须显式按_id或统一逻辑ID升序排列操作顺序，否则高并发下易触发WriteConflict或超时回滚。
MongoDB 事务本身不保证跨文档/跨集合的资源访问顺序，死锁风险主要来自应用层对资源的无序争抢——必须由你显式控制访问顺序，否则即使启用事务也大概率触发写冲突或超时回滚。
为什么 MongoDB 没有“自动锁排序”机制
MongoDB 的 WiredTiger 存储引擎只提供文档级锁（非行级），且事务内部不强制资源加锁顺序。它依赖两阶段提交协议保障原子性，但不构建全局等待图，尤其在分片集群中，各 shard 独立管理本地锁，无法感知跨节点循环等待。这意味着：一旦事务 A 先更新 users 再更新 orders，而事务 B 反过来先改 orders 再改 users，就极易在高并发下形成分布式死锁——MongoDB 不会主动检测或打破它，只会让其中一个事务因 WriteConflict 或 TransactionTooOld 失败。
按固定字段值排序资源 ID 是最简单有效的规避手段
核心原则：所有涉及多文档更新的事务，必须对操作对象的 _id（或业务唯一键）做升序/降序排列，再依次执行操作。这不是“建议”，而是强制约定。
- 升序是最稳妥选择，避免因随机 ID 分布导致热点集中
- 若用复合键（如
{tenant_id: 1, entity_id: 1}），需统一按完整键字典序排序，不能只排entity_id - 排序必须在事务开始前完成，不能在
session.StartTransaction()后动态决定顺序 - Go 驱动示例中，
sort.Slice(ids, func(i, j int) bool { return ids[i].Hex() 是常见做法；PHP/Laravel 则常用 <code>collect($ids)->sort()->values()->all()
跨集合事务更要统一资源命名空间
当一个事务同时操作 products、inventories 和 logs 集合时，“按 _id 排序”不再足够——不同集合的 _id 类型和取值范围无交集。此时必须引入逻辑资源标识（Logical Resource ID）：
- 构造统一格式的字符串 ID，例如
"product:65a1b2c3"、"inventory:65a1b2c3"、"log:65a1b2c3" - 所有事务均按该字符串升序排列并依次访问对应文档
- 避免使用数字 ID 混合类型（如
1001表示 product，2001表示 inventory），易因位数差异导致排序错乱 - 该逻辑 ID 必须可索引、不可变，且在事务内全程复用，不能每次查询都重新生成
注意 TTL 和 lottery 清理机制掩盖不了顺序缺陷
像 Laravel-MongoDB 的 MongoLock 使用 lottery 参数随机清理过期锁，或靠 TTL 索引自动删锁，这些只是兜底容错，无法防止两个正常运行的事务因访问顺序相反而卡住。它们解决的是“锁残留”，不是“锁竞争”。如果你看到日志里频繁出现 WriteConflict 错误，或者 mongostat 显示 locks 字段持续为 1，基本可以断定是资源访问顺序没对齐——这时候调大 transactionLifetimeLimitSeconds 或加重试次数，只是让失败来得更慢，而非根治。
