必须用游标流式消费并显式关闭，避免toArray()导致内存溢出；控制batchSize、禁用累积数组、让出主线程触发GC；升级驱动至5.0+并配置连接池与超时选项。
游标没手动关闭，查完就崩
Node.js 用 find() 查几百万文档时，如果只调用 toArray() 或直接 forEach()，MongoDB 驱动会把全部结果一次性拉进内存 —— V8 堆直接爆掉，报 FATAL ERROR: Ineffective mark-compacts 不是 GC 失效，是根本没机会触发 GC，数据早塞满了。
必须用游标流式消费：用 cursor.next()、cursor.forEach()（带回调）或 for await...of（推荐），并确保游标最终被释放：
-
for await循环结束后，驱动自动调用cursor.close()，但前提是没提前break或抛错；加try/finally显式关游标更稳 - 避免
cursor.toArray()，哪怕加了limit(1000)，它仍会预分配数组、触发多次内存拷贝 - 聚合管道里慎用
$group或$sort，它们可能把中间结果全缓存在内存里，改用allowDiskUse: true
Node.js 默认堆内存不够撑住批量处理
V8 默认堆上限约 1.4GB（64位），查 50 万条文档、每条 2KB，光 JSON 解析后对象就占 1GB+，再叠加上临时变量、闭包引用，溢出纯属正常。
不靠调大 --max-old-space-size 治标，得从代码层减压：
- 用
cursor.batchSize(1000)控制每次从 MongoDB 拉多少条（不是 limit！是网络批次） - 处理逻辑里别累积数组：
let results = []然后push是最常见陷阱；改用单条处理 + 异步写入（如insertMany分批） - 确认
node --v8-options | grep max_old_space_size看当前限制，线上环境建议显式设为--max-old-space-size=3072（3GB），但别超物理内存 70%
GC 没时间跑，因为 JS 主线程一直被阻塞
游标遍历本身不卡，但如果你在 for await 里同步做重计算、字符串拼接、或调用没 await 的 Promise，事件循环就被锁死，V8 的增量 GC 根本没机会切片执行。
典型表现：CPU 占用冲到 100%，内存曲线陡升，几秒后直接 FATAL。解决关键是「让出主线程」：
- 每处理 N 条（比如 100 条），加一次
await new Promise(resolve => setImmediate(resolve))，强制让 GC 插队 - 避免在循环里
JSON.stringify()大对象，它 CPU 和内存双杀；真要日志，只打_id或摘要字段 - 检查是否有未
await的db.collection().insertOne()，这种“火球型” Promise 一旦堆积，等于批量制造待 GC 对象
MongoDB 驱动版本和游标选项不匹配
老版本驱动（比如 3.x）的 find() 返回的是类数组对象，for await 不生效；新驱动（4.13+）默认启用 useUnifiedTopology: true，但若服务端 MongoDB 版本低于 3.6，游标超时行为会异常，导致连接堆积、内存泄漏。
关键配置项必须对齐：
- 驱动升级到
^5.0.0以上，用原生AsyncIterator支持，别自己封装next()循环 - 连接字符串加
?maxPoolSize=10&minPoolSize=5，防游标未关导致连接耗尽，间接拖垮内存 - 游标创建时显式传
{ noCursorTimeout: true }，否则默认 10 分钟超时，超时后服务端清理而客户端还拿着引用，变成悬空对象
真正麻烦的从来不是查多少，而是查完之后你顺手干了什么 —— 一个没 await 的日志、一次忘记 close() 的游标、一段同步字符串处理，都比数据量本身更容易捅穿内存底线。
