嵌入式购物车在高并发下必然丢更新、写放大、无法原子操作，必须拆分为引用式分集合建模并用findoneandupdate+version实现乐观锁；因其全量重写数组、覆盖写丢失更新、索引不稳定致错位；分集合后单商品操作无写放大，支持细粒度乐观锁与跨集合事务。
单文档嵌入式购物车模型在高并发下必然丢更新、写放大、无法原子操作——必须拆分为引用式分集合建模，并配合 findOneAndUpdate + version 字段实现乐观锁。
为什么嵌入式购物车撑不住并发更新？
把 items 数组直接塞进 Cart 文档，表面省事，实际埋了三颗雷：
- 每次增删商品都得全量重写整个
items数组，哪怕只改一个quantity，BSON 序列化+日志写入体积翻倍 - 两个请求同时读出同一份
items，各自修改后$set回去，后到的会覆盖前一次变更（丢失更新） - 没法对单个商品做原子操作：你想只更新某 item 的
price，但$set必须带路径items.0.price，而索引不稳定（数组位置可能变），容易错位
用引用式分集合建模替代嵌入
把购物车主体和商品条目拆成两个集合，靠 cart_id 关联，结构更可控：
{
"_id": "cart_abc123",
"user_id": "u456",
"status": "active",
"version": 1,
"updated_at": "2026-07-21T14:30:00Z"
}
{
"_id": "item_xyz789",
"cart_id": "cart_abc123",
"product_id": "p999",
"quantity": 2,
"price": 89.9,
"version": 1,
"created_at": "2026-07-21T14:25:00Z"
}
好处很实在：
- 加/删/改单个商品，只操作
cart_items集合里一条文档，写放大归零 - 每个
cart_item可独立加version，支持细粒度乐观锁 - 查购物车时用
aggregate+$lookup拼装，虽然多一次网络往返，但换来的是可伸缩性和事务能力（比如扣库存+加购物车要跨集合一致性）
高并发更新必须配 findOneAndUpdate + version
别信事务能救单文档更新——transaction 在 WiredTiger 层对整条文档加 X 锁，高并发直接排队，触发错误码 112 或 129。真正靠谱的是乐观锁：
- 插入购物车时，必须显式设
version: 0（不能是null或字符串"0"） - 更新前读出当前
version，匹配条件写成{ _id: cartId, version: oldVersion }，不能用$ne: null - 更新操作里必须用
$inc: { version: 1 }，不能$set: { version: oldVersion + 1 }，否则破坏原子性 - Node.js Driver 4.x+ 默认
returnDocument: 'before'，重试时拿不到新version，务必显式设returnDocument: 'after'
重试逻辑里最容易漏掉的三件事
很多人写个 while (matchedCount === 0) 就以为万事大吉，结果线上静默丢数据：
- 重试时不能复用第一次读出的
items数组快照——必须重新findOne拿最新版，否则你是在拿过期数据反复撞墙 - 如果更新前调用了发短信、扣第三方账户等外部服务，这些操作必须幂等；否则重试会重复发通知、重复扣款
- 除了检查
matchedCount === 0，还得捕获result.lastErrorObject?.code === 11000（唯一键冲突），比如用户同时加两个相同商品，可能因索引约束失败
version 字段不是装饰，是乐观锁的命门；它不自动递增、不校验类型、不拒绝字符串——全靠你代码里盯死。
