购物车不应默认用嵌入式文档建模，尤其在高并发写入、跨设备同步或需参与库存/优惠计算时，易出现数据丢失、一致性差与扩展性瓶颈；应优先采用引用式建模（carts + cart_items 两集合），以支持事务、审计、实时标记等业务需求。
购物车不该默认用嵌入式文档建模，尤其当并发写入、跨设备同步或需参与库存/优惠计算时，嵌入式结构会快速暴露一致性与扩展性问题。
嵌入式 cart.items 数组为什么在高并发下容易丢数据
每次增删商品都得全量更新整个 items 数组，MongoDB 的 $set 或 $push 操作不是原子到数组元素粒度的。两个请求同时修改同一购物车（比如用户在手机和网页端各加一件），可能产生“后写覆盖前写”的情况——例如 A 加了商品 X，B 加了商品 Y，最终只存下 X 或只存下 Y。
-
updateOne({ _id: "cart_123" }, { $push: { items: newItem } })看似简单，但没做并发控制，也不校验当前items状态 - 用
$addToSet也不能解决数量叠加问题（比如两次加同一商品，应合并为 quantity=2，而非插入两条） - 没有事务包装时，
$inc更新单个 item 的quantity必须先查再改，中间窗口期可能被其他写入干扰
什么时候该拆成 carts + cart_items 两个集合
当你需要以下任一能力时，引用式建模是更稳的选择：跨登录态合并购物车、商品失效实时标记、优惠券绑定状态独立更新、审计操作留痕、后续迁移到金仓等强一致数据库。
-
carts集合只存元信息：_id、user_id、created_at、updated_at -
cart_items集合每行一个商品条目，关键字段包括：cart_id、product_id、quantity、price_snapshot、coupon_applied - 在
cart_items上建复合唯一索引：{ cart_id: 1, product_id: 1 }，避免重复添加 - 加购逻辑用
updateOne+upsert: true+$inc: { quantity: 1 }，天然支持并发安全
聚合查询性能怎么不掉太多
拆成两个集合后，查购物车确实要 $lookup，但只要索引到位，延迟并不明显。真正拖慢的是没索引或没限制返回字段。
- 必须在
cart_items.cart_id上建索引，否则$lookup会全表扫描 - 聚合管道里用
$project显式指定需要的字段，避免把price_snapshot、coupon_applied等不展示的字段也拉回来 - 如果前端只需要商品 ID 和数量，就别在
$lookup后$mergeObjects拼完整商品文档——让商品服务单独查products集合更合理 - 对未登录用户，仍可用 Session 存临时
cart_id或轻量商品 ID 列表，不走 MongoDB 查询
嵌入式模型不是完全不能用，但得守住边界
仅适用于：未登录用户临时加购、关闭浏览器即清空、无库存预占、无优惠叠加逻辑、QPS 低于 50 的小流量后台系统。
- 嵌入式结构读快，但一旦要加“失效时间”“来源渠道”“赠品标记”等字段，
items数组很快膨胀，单文档逼近 16MB 限制 - 更新单个 item 的任意字段（比如价格快照变更）必须重写整个数组，写放大严重，影响副本集同步延迟
- 无法对
cart_items单独建 TTL 索引实现自动过期，只能靠应用层定时清理整个 cart 文档
最容易被忽略的点是：购物车模型选型不是技术洁癖问题，而是业务水位的映射。当“加购→锁库存→核销优惠→生成预订单”开始串成一条链路时，文档结构就不再是读写效率问题，而是事务边界的定义方式。这时候再回头改模型，代价远高于初期多写几行 $lookup。
