在MongoDB聚合管道中，数据结构的重塑往往从$project阶段开始。它远不止是筛选字段那么简单，而是重新定义字段、计算新值、甚至构建嵌套子文档的核心工具。然而，许多开发者误将其等同于SQL中的SELECT投影，常犯两个错误：一是未将_id显式设为0，导致多余字段影响后续处理；二是混合使用1和0的写法，造成语法错误。

$project 阶段是数据模型转换最直接且常用的途径，并非可选项，而是绝大多数结构重塑任务的起点。

使用 $project 重新定义字段结构

正确用法十分明确：显式列出所有需要保留的字段，未列出的默认被丢弃（除非使用 _id: 1 保留）。计算字段支持直接编写表达式，例如通过 $concat 将 $first_name 和 $last_name 拼接为 full_name。嵌套结构可任意深度，如 profile: { age: "$age", city: "$address.city" } 可一步提取地址中的城市字段。删除字段则设为 0，但注意不能与表达式混用于同一字段名，否则MongoDB将报错。

处理数组字段：从嵌套展开到扁平化

当原始文档中包含数组字段（例如 orders.items），需要将其展开为多条记录再进行聚合时，$unwind 是必备工具。但此操作容易导致“爆炸式膨胀”——比如一个包含5个商品的订单，展开后变成5条记录，若不预先过滤，性能会急剧下降。因此，建议在 $unwind 之前先使用 $match 缩小数据范围，例如只筛选 status: "completed" 的订单。如果数组可能为 null 或空，请添加 preserveNullAndEmptyArrays: true 参数，否则该文档将被舍弃。展开后通常需要配合 $group 进行聚合，比如按 order_no 分组统计，此时应使用 $first 提取非数组字段（如用户信息）。

跨集合关联时字段类型不匹配如何解决？

很多 $lookup 匹配失败并非逻辑错误，而是由于ID类型不匹配：一侧是 ObjectId，另一侧是字符串 "123"。不要依赖应用层硬编码拼接字符串，而应在聚合管道中使用类型转换操作符。使用 $toString 将ObjectId转为字符串以匹配字符串ID字段；反之，使用 $toObjectId 将字符串转为ObjectId（前提是字符串格式正确）。如果目标字段可能为 null 或格式不统一，先用 $cond 进行条件判断再转换，避免整个阶段报错。$lookup 的 pipeline 选项中也可以嵌套这些转换，不要只关注外层。

写入新集合还是直接返回？选错会影响开发效率

$out 和 $merge 均可将结果写入新集合，但行为截然不同。选择错误可能导致数据被清空或冲突覆盖。$out 执行全量替换：若目标集合已存在则清空重写，不存在则新建；适用于定时批处理生成报表。$merge 执行增量更新：可指定匹配键（例如 on: "_id"），已存在时选择 replace 或 keepExisting，适合持续数据同步场景。本地调试时建议先使用 .toArray() 或 Compass 预览结果，确认逻辑正确后再添加 $out，否则误操作无法撤销。

真正具有挑战性的并非编写单个stage，而是stage之间的数据形态衔接——上一阶段输出的字段名称、类型以及可能的null值，直接决定了下一阶段能否安全引用。在嵌套使用 $lookup 或多次 $unwind 时尤其容易出错。这才是实际开发中的核心考验。