投影嵌套字段必须用点号路径如"user.profile.avatar"，不能用{"parent": {"child": 1}}语法；数组索引如"items.0.name"有效但需谨慎；排除_id须显式写"_id": 0；投影不补全缺失字段且不报错。
投影嵌套字段时必须用点号路径，不能用对象嵌套语法
很多人写 {"parentfield1": {"childfield2": 1}} 以为能只取子字段，结果 MongoDB 直接忽略这个写法，返回整个 parentfield1 对象。投影只认扁平化的点号路径，比如 "parentfield1.childfield2" —— 这是硬性规则，不是风格偏好。
常见错误现象：
- 查询返回了完整嵌套对象，明明只想取其中一两个字段
- 使用
{$project: {parentfield1: {childfield2: 1}}}，结果报错或无效果
正确做法：
- 所有嵌套字段都展开成字符串路径：
"user.profile.avatar"、"orders.0.amount" - 数组索引支持但需谨慎：
"items.0.name"只取第一个元素的 name，如果数组为空则该字段不出现 - 排除
_id时必须显式写"_id": 0，否则它默认总在结果里
嵌套数组字段投影要搭配 $elemMatch 或位置操作符才精准
对数组字段做投影时，"comments.text": 1 这种写法会把整个 comments 数组里每个元素的 text 都拉出来，但如果你只想匹配特定条件的那条评论，光靠投影不够。
使用场景：
- 查用户最近一条带关键词的评论，只取其
text和date - 订单列表中只显示状态为
"shipped"的物流信息
实操建议：
- 先用
$elemMatch在 query 阶段缩小数组范围：{"comments": {$elemMatch: {"score": {$gte: 4}}}} - 再用投影限定返回字段：
{"comments.text": 1, "comments.score": 1} - 若需保留数组结构（避免展平），必须配合聚合管道和
$filter，单纯find()投影做不到
投影无法“补全”缺失字段，但也不会报错或中断查询
你写 {"user.address.zip": 1, "user.contact.email": 1}，而某文档里 user.contact 根本不存在——MongoDB 就安静地不返回 contact 字段，不会抛错，也不会塞个 null 占位。这点和 SQL 的 LEFT JOIN 行为完全不同。
影响与风险：
- 前端代码如果假设某个嵌套路径一定存在，可能触发
Cannot read property 'email' of undefined - 聚合阶段后续处理（如
$addFields）若依赖该字段，需提前用$ifNull做兜底 - 调试时容易误判数据缺失是写入问题，其实是投影+数据本身就不全
建议在业务层明确约定：对可选嵌套字段，消费方必须做空值检查；服务端不因投影写法而改变数据存在性语义。
嵌套投影 + 索引组合才能真正压低延迟和带宽
只加投影不建索引，相当于把“传输压力”从网络搬到了数据库内存和磁盘 I/O 上。尤其当集合大、嵌套深、查询并发高时，find({ "user.status": "active" }, { "user.name": 1, "user.avatar": 1 }) 若没在 user.status 上建索引，MongoDB 仍得扫全表再裁剪字段。
关键点：
- 投影本身不加速查询，它只减少返回体积；索引才决定扫描效率
- 复合索引可覆盖投影字段：
db.users.createIndex({"user.status": 1, "user.name": 1, "user.avatar": 1})让查询完全走索引，连文档都不用读 - 注意 WiredTiger 的文档级缓存：小投影 + 高频访问 = 更高缓存命中率，但前提是索引让查询足够快，否则缓存还没热起来请求就超时了
最容易被忽略的是：嵌套字段索引名必须和投影路径一致。比如你总投 "profile.settings.theme"，索引就得建在 "profile.settings.theme"，而不是 "profile" 或 "settings" —— 后者根本用不上。
