MongoDB的projection参数必须显式传入且格式合法：用纯对象，值仅限1/true/0/false，不可混用包含与排除；_id是唯一可单独排除的字段；数组精准筛选须用聚合管道$filter。
projection参数怎么写才不被MongoDB忽略
MongoDB的projection不会自动生效，必须显式传入查询选项对象，且不能和filter混在同一个对象里。常见错误是把字段开关直接写在find()第一个参数里，比如collection.find({ name: "Alice" }, { name: 1, email: 1 })——这在较新驱动（v4+）中会被当作filter和options分开处理，但若漏掉projection键名，驱动就当没这回事。
正确写法必须明确使用projection字段：
collection.find(
{ status: "active" },
{ projection: { _id: 0, name: 1, email: 1 } }
)
-
_id: 0要单独写，不能和其他1字段挤在一条规则里（MongoDB不支持混合投影模式） - 如果只用
{ name: 1, email: 1 }而没包进projection，Node.js驱动（v4.12+）会静默忽略，返回全部字段 - 聚合管道中不用
projection字段，而是用$project阶段，语法完全不同
为什么{ name: 0, email: 0 }报错：Excluded fields aren't allowed in inclusion projection
这是MongoDB的硬性限制：一旦用了1（包含模式），就不能再出现0（排除模式），反之亦然。错误示例：{ _id: 0, name: 1, email: 0 }会直接抛出MongoInvalidArgumentError。
解决方式只有两种，选其一：
- 全用
1：显式列出要返回的字段，_id默认包含，如需剔除必须加_id: 0 - 全用
0：只列出要排除的字段，_id仍默认返回（不能设为_id: 1，否则报错）
例如想返回name和email，去掉_id和password，只能写成：
{ projection: { _id: 0, name: 1, email: 1 } }
而不是试图用0去排除password——它根本不会出现在结果里，除非你主动查它。
findOne()和find().toArray()对projection的处理有区别吗
没有本质区别，驱动层统一走同一套投影逻辑。但容易踩坑的是调用时机和返回结构：
-
findOne()返回单个文档，projection作用于该文档，行为直观 -
find().toArray()返回数组，每个元素都按相同projection过滤，但如果你忘了await或没接Promise，可能拿到空数组或undefined，误以为投影失效 - 流式遍历（
find().forEach()）同样受projection影响，但错误常出现在异步回调里没正确处理this或闭包变量
最稳妥的写法是始终显式await并检查返回值类型：
const user = await collection.findOne({ uid: 123 }, { projection: { _id: 0, name: 1 } });
别依赖find().next()这类底层方法，除非你清楚游标生命周期。
projection会影响索引使用和查询性能吗
不影响索引选择，但可能影响实际执行效率。MongoDB能在覆盖索引（covered index）场景下完全避免读取文档内容——前提是projection里所有字段都在索引中，且没用到$text、正则等无法索引的操作。
- 例如有复合索引
{ name: 1, email: 1 }，查询find({ name: "Bob" }, { projection: { name: 1, email: 1, _id: 0 } })可走覆盖索引 - 但如果
projection里加了bio: 1（不在索引中），就必须回表查完整文档，失去覆盖优势 -
_id字段无论是否投影，只要索引含_id，它总在内存里；但设_id: 0能减少网络传输量，尤其大批量查询时
真正容易被忽略的是：projection本身不降低查询复杂度，它只减少返回数据量。如果业务需要频繁查大字段（如content文本），应该考虑拆表或延迟加载，而不是只靠projection“掩耳盗铃”。
