在 MongoDB 中，limit() 看起来简单，但实际使用中踩坑的开发者不在少数。先理清几个核心要点：它不是集合方法，不能单独调用；limit(0) 的含义与直觉完全相反；与 skip() 配合时，性能问题远比想象中更突出。下面逐条深入解析。
limit() 必须链式调用在 find() 之后
首先说最常见的新手错误：直接写 db.collection.limit(10) 会抛出 TypeError。为什么？因为 limit() 是游标（cursor）方法，而非集合方法。只有 find() 或 aggregate() 返回游标后，才能链接调用。这好比你不能对着空篮子说“给我拿5个苹果”——篮子必须先有内容。
db.users.find({status: "active"}).limit(5)✅ 正确用法db.users.limit(5)❌ 直接报错db.users.find().limit(-1)⚠️ 负数会被转成正数，但语义模糊——不建议这样写，容易让团队成员困惑
很多从 SQL 转过来的开发者习惯把 LIMIT 当作独立关键字使用，但在 MongoDB 中行不通。记住：limit() 是游标的装饰器，不是集合的开关。
limit(0) 等价于不限制，而非“返回 0 条”
这个陷阱尤其隐蔽。你可能会想：“我写 limit(0) 不就返回零条了吗？” 错！MongoDB 官方文档明确指出：limit(0) 表示“无限制”，实际行为等同于没有添加 limit()，所有文档都会被返回。这不是 bug，而是设计使然。
想确保结果为空？不要依赖 limit(0)，老老实实加一个永远不匹配的条件，比如 {_id: null} 或 {$expr: false}。
db.logs.find().limit(0)→ 返回全部文档（你担心了吗？）db.logs.find({$expr: false}).limit(10)→ 确定返回 0 条
因此，写代码时千万别把 limit(0) 当作“清空结果”的捷径——它只会让数据量失控，严重时可能导致内存溢出或性能下降。
和 skip() 搭配时，skip 总是先执行
分页场景下，skip() 和 limit() 经常一起使用。有意思的是：无论你写成 .skip(20).limit(10) 还是 .limit(10).skip(20)，MongoDB 内部都先执行 skip()，跳过 N 条，再取 M 条。写法顺序不影响结果数量，但影响性能——因为被跳过的文档仍然需要扫描、解序列化，只是不返回给客户端。
页数越大，skip() 就越慢。假设每页 20 条，翻到第 1000 页，实际要跳过 19980 条。这在千万级集合里就是灾难。行业通用的优化方案是改用游标分页（cursor-based pagination）：利用 $gt 加索引字段，而不是依靠 skip()。
另外必须强调：没有显式 sort() 的情况下，skip()+limit() 的结果是不稳定的。因为无索引时游标的文档顺序不保证——同一查询分两次执行，可能得到不同页的数据。因此，分页时一定要加上 sort() 指定排序字段，确保顺序一致。
Node.js 驱动里 limit() 返回的是 Cursor，不是数组
如果你在 Node.js 中写 collection.find().limit(5)，得到的是一个 FindCursor 对象，而不是数组。直接 console.log(cursor) 什么都看不到——必须通过 toArray()、forEach() 或 next() 才能消费数据。
新手高频翻车现场：忘记 await 或 .then()，结果打印出 Promise 或空对象。正确的写法是：
await collection.find({x: 1}).limit(3).toArray()✅ 拿到数组collection.find({x: 1}).limit(3).toArray()❌ 返回 Promise，不 await 就是 pendingcollection.find({x: 1}).limit(3).next()→ 只取第一条，适合单条场景
更隐蔽的是：limit() 生效的前提是游标还没被消费。一旦调用了 toArray() 或遍历过一次，再链 limit() 就无效了——它只作用于尚未读取的游标阶段。所以务必在消费数据前完成所有链式调用。
