先说一个核心结论：当你在 Node.js 中通过 Mongoose 读取 MongoDB 数据时，查询几千条记录就感觉响应缓慢，绝大多数情况下问题并不出在数据库本身，而是 Mongoose 默认的“响应式机制”造成了性能瓶颈。每个返回的 Mongoose Document 实例都集成了变更追踪、getter/setter、验证钩子、虚拟属性等完整功能——当这些功能附加到成百上千条记录上时，内存占用飙升、序列化效率下降、垃圾回收频繁触发，响应时间自然成倍增长。解决方案其实非常直接——使用 .lean() 方法让查询直接返回普通 JavaScript 对象（POJO）。不过，这个方法有几个容易踩坑的细节，很多开发者都曾遇到过。
为什么直接查询 MongoDB 大量数据会导致性能下降
默认情况下，Mongoose 查询返回的是 Mongoose Document 实例，而非普通 JavaScript 对象。每个实例都内置了完整的响应式机制：变更追踪、getter/setter 拦截器、数据验证钩子、虚拟属性支持等。当一次性查询出数千条记录时，这些附加功能的开销会呈现指数级增长——内存消耗剧增、序列化速度降低、垃圾回收压力加大，最终拖慢整体响应速度。
lean() 必须在查询链末尾调用，无法事后追加
.lean() 是一个查询选项，必须放置在 find()、findOne()、findById() 等方法之后、.exec() 或 await 之前。它不是对已返回结果进行“格式转换”，而是在查询执行前就指示 Mongoose：“不要封装为 Document，直接返回 POJO”。
- ✅ 正确：
Item.find({ status: "active" }).lean().exec()或await Item.find({ status: "active" }).lean() - ❌ 错误：
await Item.find({ status: "active" }).exec().lean()（报错：TypeError: exec(...).lean is not a function） - ❌ 错误：
const docs = await Item.find({}); docs.map(d => d.toObject().lean())（.toObject()不是.lean()，且已晚）
lean() 返回的对象无法再调用 Document 方法
启用 .lean() 后，查询返回的是纯 Object，不再包含 .sa ve()、.validate()、.toObject()、.toJSON() 等 Document 方法。如果你需要：
- 如果需要保留虚拟属性（例如
fullName），可以添加.lean({ virtuals: true }) - 如果需要保留
toObject()行为（如自定义transform逻辑），需手动实现，或改用.toObject({ getters: true, virtuals: true })配合非 lean 查询 - 如果后续需要更新该数据，则不能使用
.lean()，必须重新发起一次非 lean 查询来获取可操作的 Document 实例
结合 $in 与 Map 提升大批量关联查询性能
在处理购物车列表并拼接商品详情等场景时，避免使用 for...of 配合 await getItemById(id) 进行串行查询——即使每个查询都使用了 .lean()，总耗时依然会线性累积。推荐的做法是：
- 首先使用
cartItems.map(i => i.itemId)提取所有商品 ID - 然后通过一次
Item.find({ _id: { $in: itemIds } }).lean()查询获取全部商品数据 - 接着使用
new Map(items.map(i => [i._id.toString(), i]))构建 ID 到商品对象的映射 - 最后遍历
cartItems，从 Map 中取出对应商品并直接挂载count、filter等字段
这一组合方案将 N 次独立查询压缩为 1 次批量查询，.lean() 降低了单次返回的数据处理开销，Map 查找实现 O(1) 时间复杂度，三者协同作用的效果远胜于单独使用 .lean()。
最容易被忽略的一点是：.lean() 只解决了“返回对象是否可修改”的问题，并不能决定“查询多少条数据才合理”。如果接口设计本应分页却一次性拉取 10 万条记录，即使添加了 .lean() 也无法挽救内存和网络传输方面的瓶颈——该加 limit 限制、该做分页处理、该建数据库索引的地方，一个都不能少。
