需先$match过滤当前用户购物车，再$unwind展开items数组，然后$group按productId求$sum，最后$project重命名字段；若需价格则用$lookup关联products并$type转换防错。
聚合管道里怎么把多个购物车条目合并成一条商品汇总？
直接用 $group 按 productId 分组，再用 $sum 累加数量——但要注意：不同用户、不同会话的购物车不能混在一起。必须先用 $match 过滤出当前用户的全部购物车文档（比如 userId: "u123"），再对每个 productId 合并数量。
常见错误是漏掉 $unwind：如果购物车文档里存的是数组字段（如 items: [{ productId: "p1", qty: 2 }, ...]），得先 $unwind 展开，否则 $group 会把整条数组当一个单元处理。
- 必须确保输入文档结构一致，比如所有购物车都用
items字段存商品列表 - 若存在“同一商品多次添加但未合并”的情况，
$group是唯一可靠合并方式，别试图用应用层去 dedupe - 分组后记得用
$project重命名字段，比如把_id改成productId，避免后续步骤混淆
怎么在聚合里查商品单价并实时计算小计？
不能靠应用层查一次再塞回去——那样要两轮数据库交互，且并发时价格可能已变。应该用 $lookup 关联 products 集合，在管道内完成价格注入。
关键点在于：如果 products 集合里有多个版本的价格（比如带有效期字段），得在 $lookup 的 pipeline 里加 $match 过滤有效价格；否则可能关联出多条或空结果。另外，$lookup 返回的是数组，需用 $arrayElemAt 取第一个（假设价格唯一）或 $reduce 找最新价。
-
$lookup的from必须写集合名，不是变量名，比如from: "products" - 别在
$lookup外层直接用$multiply: ["$qty", "$price"]——因为$price在$lookup结果里是嵌套的，得先$addFields提出来 - 如果商品不存在（
$lookup返回空数组），$arrayElemAt会返回null，乘法会得null，建议用$ifNull设默认价防崩
为什么 $sum 计总价老是算错？
问题通常出在字段路径和数据类型上。$sum 遇到非数字值（比如字符串 "9.99" 或缺失字段）会跳过或返回 0，不报错但结果不对。
必须在计算前统一转类型：用 $toDouble 或 $toInt 显式转换，再配合 $ifNull 处理空值。例如：{ $sum: { $multiply: ["$qty", { $toDouble: { $ifNull: ["$product.price", 0] } }] } }。
- 别依赖应用层保证数据类型干净——MongoDB 是 schema-less 的，同一字段在不同文档里可能是字符串、数字或 null
-
$sum对数组求和时，只对数组内元素生效；如果字段本身是单值，别误包一层数组 - 总价字段名建议用
totalAmount而非total，避免和$group的_id冲突或被其他聚合阶段覆盖
合并购物车时怎么保留促销信息和库存状态？
促销和库存往往不在购物车文档里，需要额外关联。可以在同一个聚合里串行做多个 $lookup：一个查 promotions，一个查 inventory。但注意顺序——促销规则常依赖库存量，所以先查库存，再用库存量匹配促销条件（比如“满 2 件打 9 折”）。
复杂促销逻辑（如阶梯价、跨商品满减）不适合全在聚合里写死，建议只查基础字段（discountRate, minQty），把判断逻辑留给应用层。聚合阶段只负责把原始数据准备好。
- 每个
$lookup都会增加查询延迟，超过 2 个关联时要考虑是否拆成多次聚合或预聚合 - 库存字段（如
availableStock）应设为数字类型，避免用字符串导致比较失效 - 如果促销有时间范围，
$lookuppipeline 里必须加{ $match: { startsAt: { $lte: "$$NOW" }, endsAt: { $gte: "$$NOW" } } }
最易被忽略的是错误兜底：聚合管道一旦某个阶段出错（比如字段不存在、类型不匹配），整个管道就中断，返回空结果。上线前务必用真实脏数据测一遍，尤其检查 $ifNull 和类型转换是否覆盖所有分支。
