投影本身不能减少网络传输，只有索引覆盖查询条件、投影字段及排序字段（如有）且totaldocsexamined=0时才真正省流量；否则仍需读取完整文档再裁剪。
投影本身不能减少网络传输——只有配合索引覆盖时才真正省流量。 单纯加 projection 只是让服务端裁剪返回字段，但文档仍得从磁盘读、解码、再裁，该传的字节一个没少。真正压低网络开销，得让 MongoDB 连文档都不用读。
为什么 db.collection.find(query, projection) 还是传了很多数据？
因为默认情况下，find() 执行的是「索引查找 + 回表取文档 + 字段裁剪」三步。哪怕你只想要两个字段，只要这两个字段不在查询所用的索引里，MongoDB 就必须把整条 BSON 文档加载进内存，再按 projection 删减——这部分被删掉的字段，已经走完网络了。
- 判断是否真省流量：跑
db.collection.explain("executionStats")，看"executionStage": "IXSCAN"且"totalDocsExamined": 0 - 一旦
totalDocsExamined > 0，说明文档被读了，投影只是“事后减肥” - 常见破防点：
_id默认包含，但你没在索引里声明它（或显式设_id: 0），就会强制回表
如何建一个能支撑投影免读文档的索引？
索引必须同时覆盖「查询条件字段」「投影字段」和「排序字段」（如有）。缺一不可。
- 示例查询：
db.orders.find({ status: "done" }, { projection: { user_id: 1, amount: 1, _id: 0 } }) - 对应索引必须含：
status（等值条件）、user_id、amount（投影字段）、且明确排除_id（因_id: 0） - 正确建法：
db.orders.createIndex({ status: 1, user_id: 1, amount: 1 }) - 错误建法：
{ user_id: 1, status: 1, amount: 1 }（等值字段status不在最左，无法高效跳转） - 别把无关字段塞进去，比如
created_at——不查不投，纯增索引体积和写开销
嵌套字段和数组怎么安全投影？
嵌套路径投影有效，但数组要格外小心：tags.$ 只返回第一个匹配项；想取多个，find() 无解，必须上聚合管道。
- 安全写法：
{"profile.name": 1, "profile.email": 1}—— 明确路径，可被索引覆盖 - 危险写法：
{"tags": { "$elemMatch": { "type": "featured" } }}配合{"tags.$": 1}—— 表面轻量，实则触发文档加载（$elemMatch不支持索引覆盖） - 数组多匹配需求：只能用聚合，例如
{$project: { featuredTags: { $filter: { input: "$tags", cond: { $eq: ["$$this.type", "featured"] } } } }} - 注意：
$filter是聚合阶段，find()的projection不认它
最容易被忽略的一点：索引覆盖对字段顺序敏感，也对 _id 的显式控制敏感。线上看到 projection 没降带宽，第一反应不该是“是不是 projection 写错了”，而是立刻 explain 看 totalDocsExamined——值不是 0，所有优化都白搭。
