内嵌数组方案在高并发下会导致数据丢失，因$push/$pull无法保证多请求对同一数组的原子性更新，易引发WriteConflict、文档碎片和查询性能劣化；生产环境应改用独立cart_items集合，按user_id+sku_id建索引，配合upsert与TTL过期控制，实现精准、安全、可扩展的购物车管理。
内嵌数组方案在高并发下会丢数据
用户频繁加减商品时，$push 和 $pull 操作无法保证原子性——两个请求同时更新同一数组，MongoDB 可能只应用其中一个，导致购物车数量“跳变”或“回退”。监控里常看到 WriteConflict 报错飙升，avgObjSize 持续上涨，说明文档因反复重写产生碎片。
这不是配置问题，是模型缺陷：内嵌数组只适合单用户、少商品、低频操作的原型阶段。生产环境一旦用户量过万、平均购物车商品超 5 个，就必须放弃。
- 每次
updateOne都要读写整个文档，网络+磁盘开销翻倍 - 无法对单个商品项建索引，查“某用户有没有某 SKU”只能全表扫
cartList.productId -
$pull默认匹配所有同product_id元素，但用户可能加了同款不同规格（如颜色/尺码），结果误删全部
生产首选：用单独集合 + user_id 索引
建一个 cart_items 集合，每条记录对应“一个用户的一个购物车条目”，字段至少包含：user_id、product_id、sku_id、quantity、updated_at。这样所有操作都走 upsert，天然并发安全。
关键索引必须建：db.cart_items.createIndex({ user_id: 1, sku_id: 1 })。加商品时用 updateOne 带 upsert: true；删商品直接 deleteOne；改数量就是带条件的 updateOne。没有数组重写，没有写放大，后续加赠品、优惠券字段也只需扩字段。
- 避免用
ObjectId当sku_id—— 它不业务语义，且无法复用已有商品库的主键 -
updated_at必须是Date类型，不是字符串或毫秒数，否则 TTL 索引无效 - 不要把
user_id存成字符串 ID（如 "U123"），统一用 ObjectId 或长整型，减少索引体积
TTL 索引必须绑定 expires_at 字段
想让购物车“30 分钟无操作自动清空”，不能依赖插入时间，得靠用户最后一次操作时间。每次增删改商品时，同步更新 expires_at: new Date(Date.now() + 30 * 60 * 1000) 字段，再对它建 TTL 索引：db.cart_items.createIndex({ expires_at: 1 }, { expireAfterSeconds: 0 })。
注意：expireAfterSeconds: 0 表示“在 expires_at 时间点过期”，不是“写入后 0 秒过期”。如果错写成 { expireAfterSeconds: 1800 }，TTL 就按文档创建时间算，和用户行为完全脱钩。
- TTL 删除是后台异步线程执行，延迟通常 ≤ 60 秒，别指望实时消失
-
expires_at字段必须是Date类型，存字符串（如 "2026-09-07T12:00:00Z"）或数字时间戳都会让索引失效 - 清空逻辑应由业务层兜底：加载购物车时若查不到任何
cart_items，就初始化空状态，不依赖“文档是否还在”
为什么 cart 集合本身不该存 expires_at？
有人想把 expires_at 放在 carts 主集合（每个用户一条文档），看似省事，但实际埋雷：用户加一个商品就得更新整个 carts 文档的 expires_at，又回到内嵌数组的老问题——写放大、并发冲突、无法精准控制单个商品过期。
更严重的是，TTL 索引只删文档，不删数组元素。如果 carts 文档里有 50 个商品，其中 49 个已过期，TTL 不会动它们，只会等整个文档过期才删——这根本不是“购物车过期”，是“用户账号过期”。
- 过期清理粒度必须到商品项，不是用户维度
-
cart_items集合里每条记录独立过期，删完即释放空间，无残留 - 别省那一次
find查询：先查cart_items再组装购物车，比扛着文档膨胀和并发风险划算得多
