事务超时根本不是配置问题，而是模型错配：把关系型数据库的表拆分习惯搬进mongodb，导致本可单文档原子完成的操作被错误拆分为多集合+事务；应优先嵌入高频共读、低频独立更新、长度可控、大小稳定的数据，仅对真正跨聚合根的场景使用事务，并确保读操作显式指定readconcern: "snapshot"。
事务超时根本不是配置问题，而是模型错配
事务超时（TransactionTooLargeForCache 或默认 60 秒中止）在 MongoDB 中几乎从不源于“没调大 timeout”，而是事务体内塞了太多本不该跨文档的操作。你看到的是超时错误，实际病因是：把关系型数据库的「表拆分」习惯直接搬进了 MongoDB，导致本可单文档完成的业务，硬生生拆成多个集合 + 事务兜底。
先确认哪些操作其实根本不需要事务
MongoDB 单文档写入天然原子——哪怕你 $set 5 个字段、$push 一个数组、$inc 两个计数器，整个更新要么全成功，要么全失败，没有中间态。这意味着：
- 订单创建 + 订单状态初始化 + 初始日志嵌入同一文档 → 不需要事务
- 用户资料 + 默认收货地址 + 最近三次登录 IP 数组 → 更新原子，无需事务
- 商品 SKU 文档内包含库存数量、锁定数量、预留数量字段 → 扣减库存用
findAndModify一条命令搞定，无竞态
只要数据访问模式是「读/写整条业务记录」，就该优先嵌入。事务只该留给真正跨聚合根的场景，比如「优惠券核销 + 订单生成 + 积分扣除」涉及三个独立生命周期的实体。
如何判断该嵌入还是该引用
别凭直觉，用这四个条件快速决策：
- 子数据是否总是和父数据一起被读取？→ 是，嵌入
- 子数据是否会单独被更新（比如评论点赞数由异步服务单独改）？→ 是，引用
- 子数据数组长度是否有明确上限（如课程最多 20 章）？→ 是，可嵌入；若可能无限追加（如用户操作日志），必须引用
- 子数据总大小是否稳定低于 1MB（留足余量）？→ 否，引用；接近但可控，考虑压缩或截断策略
例如电商订单：订单头（金额、状态、时间）+ 订单项（商品 ID、数量、单价）+ 收货信息，全部嵌入一个 orders 文档是合理选择；但「订单物流轨迹」因持续追加且条目不可控，必须拆到独立 order_shipments 集合，用 order_id 引用。
重构后事务只保留给真正的跨域一致性
重构文档模型后，剩下的事务场景会急剧减少，此时再上事务才真正值得。注意两个硬约束：
- 事务内所有操作必须落在同一个分片键前缀下（分片集群）或同一副本集内（非分片）；跨数据库事务仅在分片集群支持
- 事务体必须幂等：用
updateOne+$setOnInsert替代insertOne，用findOneAndUpdate的upsert: true控制重复提交 - 避免在事务里做任何外部调用（HTTP、RPC、消息队列），否则重试逻辑会失控
最常被忽略的一点：事务中读操作必须显式指定 readConcern: "snapshot"，否则重试时可能读到旧快照外的数据，导致业务逻辑错乱。这不是可选项，是分布式事务一致性的前提。
