不能直接用嵌套数组存多笔交易，因会导致文档膨胀、写锁争用、查询变慢；且$push无法原子更新余额，易丢数据；必须采用账户文档仅存聚合态字段、交易独立成文档的结构，并用findOneAndUpdate条件更新保障金融级一致性。
为什么不能直接用嵌套数组存多笔交易？
很多团队第一反应是把一个账户的所有交易塞进 transactions 数组里，靠 $push 追加。这在低频场景下看似省事，但实际会触发文档膨胀、写锁争用、查询变慢三重问题。MongoDB 单文档有 16MB 上限，高频交易账户几个月就可能撑爆；更关键的是，$push 本身不保证“余额同步更新”，你得靠应用层两次写（先 push 再 $inc balance），中间出错就丢数据。
必须用单文档原子性操作的三个硬条件
真正能扛住金融级一致性的建模，只在一种结构下成立：账户主文档里只存当前余额、最后交易时间等聚合态字段，每笔交易独立成文档，并通过 findAndModify 或 findOneAndUpdate 带 upsert: true 和 returnDocument: 'after' 一次性完成「查余额 → 判定是否透支 → 更新余额 → 插入交易」四步。这不是可选项，是底线。
- 交易文档必须含
accountId、amount、type（debit/credit）、timestamp、refId（外部系统流水号） - 账户文档需建唯一索引：
{ accountId: 1 }，防止重复开户 - 交易集合必须建复合索引：
{ accountId: 1, timestamp: -1 }，否则按时间范围查最近 N 笔会全表扫
如何用 findOneAndUpdate 实现零丢失写入？
核心不是靠事务，而是靠 MongoDB 的单文档原子性 + 条件更新。下面这个操作要么全部成功，要么完全不生效，不会留下中间态：
db.accounts.findOneAndUpdate(
{
_id: "acct_123",
balance: { $gte: 100 } // 预检：余额够扣
},
{
$inc: { balance: -100 },
$set: { updatedAt: new Date() }
},
{
returnDocument: "after",
upsert: false
}
)
如果返回 null，说明余额不足，此时再走退款或拒绝逻辑；如果返回更新后的文档，立刻用同一 refId 向 transactions 集合插入新文档——这里要确保 refId 全局唯一（可用 UUID 或雪花 ID），避免因重试导致重复记账。
为什么不用 MongoDB 4.0+ 的多文档事务？
事务确实能包住账户和交易两步，但代价明确：事务默认 60 秒超时，高并发下容易卡死；必须建在副本集上，且所有参与集合要共用同一分片键（对交易流水这种天然按 accountId 分片的场景，跨分片事务直接不可用）。而上面那个 findOneAndUpdate 方案，在分片集群中依然高效——只要 _id 或 accountId 是分片键，整个操作就在单一分片内完成，无协调开销。
真正难处理的不是写入，是最终一致性校验。比如对账时发现某笔 refId 在交易表有记录，但账户余额没变动，说明那次 findOneAndUpdate 成功了但后续插入失败。这类 case 必须靠定时任务扫描缺失的 refId，而不是指望写入时一步到位。
