生产环境应使用单独集合（如cart_items）而非内嵌数组：支持并发安全、避免写放大、便于扩展；TTL索引需基于Date类型expires_at字段并设expireAfterSeconds:0，仅兜底过期清理。
购物车用内嵌数组还是单独集合？
内嵌数组只适合用户量小、商品数少、更新不频繁的场景。一旦用户购物车里加了几十个商品，每次 updateOne 都要读写整个文档，容易触发文档增长重写，写放大明显；更麻烦的是，并发添加/删除商品时，$push 和 $pull 无法保证原子性——两个请求同时操作同一个数组，可能丢掉一次修改。
用单独集合（比如 cart_items）才是生产首选：每条记录对应一个用户的一个商品项，带 user_id、product_id、quantity、updated_at 字段。这样增删改都走 upsert，天然支持并发安全，也方便后续加促销、赠品、规格等扩展字段。
常见错误现象：WriteConflict 报错频发，或购物车数量偶尔“回退”；监控发现 cart 集合的 avgObjSize 持续上涨，碎片率高。
TTL索引怎么配才真能自动清空过期购物车？
TTL 索引只能作用于**单个日期字段**，且该字段必须是 Date 类型（不能是字符串或时间戳数字）。想让购物车 30 分钟没动就消失，得在 cart 文档里存一个 expires_at 字段，写入时设为 new Date(Date.now() + 30 * 60 * 1000)，再对它建 TTL 索引：
db.carts.createIndex({ "expires_at": 1 }, { expireAfterSeconds: 0 })
注意：expireAfterSeconds: 0 表示“在 expires_at 时间点过期”，不是“从写入起 0 秒后过期”。别写成 { expireAfterSeconds: 1800 } —— 那样会按插入时间算，和用户最后操作完全脱钩。
使用场景：用户登录后加载购物车，先查 cart 文档，如果查不到，说明已过期被删，就初始化空购物车；不需要手动跑定时任务清理。
内嵌数组方案下如何避免 $pull 漏删或多删？$pull 默认匹配所有符合条件的元素，但购物车常有多个同 product_id 的条目（比如不同规格），只靠 { product_id: "P123" } 会误删全部。必须带上唯一标识，比如用 item_id（UUID 或 ObjectId）：
db.carts.updateOne(
{ _id: userCartId },
{ $pull: { items: { item_id: new ObjectId("...") } } }
)
参数差异：$pull 不支持 $or 或复杂逻辑；如果要按条件批量删（如“删掉所有库存为 0 的商品”），得先 find 出 item_id 列表，再 $pull —— 这就失去原子性，得加应用层锁或改用单独集合。
为什么 TTL 清理后 cart 文档还占空间？
MongoDB 的 TTL 删除是后台线程异步执行的，延迟通常在 60 秒内，但不保证精确；更重要的是，删掉文档后空间不会立即还给操作系统，而是进“空闲列表”供后续插入复用。如果你观察到 cart 集合 storageSize 居高不下，不是 TTL 失效，而是碎片未整理。
性能影响：频繁创建又快速过期的购物车（比如游客行为），会导致大量短生命周期文档，加剧 WT 引擎的 checkpoint 压力；这时建议把游客 cart 单独分库或加前缀（如 cart_guest_...），避免污染主 cart 集合。
真实业务里，购物车的“过期”逻辑往往不止看时间：用户下单成功要清空、用户登出要清空、商品下架要标记失效……TTL 只解决最基础的兜底，其他动作还得靠应用主动调 deleteOne 或 updateMany。别指望一个索引扛下所有清理责任。
