MongoDB聚合结果超16MB直接报错是BSON协议硬限制，需显式配置cursor选项启用游标分页，且分片集群下必须保证getMore请求路由至同一mongos节点。
聚合结果超16MB直接报错：这是BSON协议层限制，不是配置能绕过的
因为MongoDB所有网络通信都基于BSON格式，而BSON单文档硬性上限就是16MB。聚合（aggregate）最终返回的是一组文档组成的响应体，只要这个整体超过16MB，驱动或mongos就会收到errmsg: "BSONObj size xxx is invalid"或Result set too large类错误——这不是服务端拒绝，是协议本身不支持。
为什么不能像find一样用cursor分页？聚合默认不自动游标化
普通find在结果大时会自动返回cursor字段+cursorID，客户端后续发getMore拉取；但aggregate命令默认不开启游标模式，它把整个结果集序列化成一个BSON响应包发送。除非你显式加{ allowDiskUse: true, cursor: { batchSize: 1000 } }，否则哪怕结果有10万条小文档，只要总大小破16MB就失败。
-
allowDiskUse: true解决的是聚合中间结果内存溢出问题，和最终响应大小无关 -
cursor选项必须存在且batchSize设为非零值，mongod才会拆分成多轮响应 - 使用
mongosh时，db.collection.aggregate([...], { cursor: { batchSize: 1000 } })才真正启用游标；省略cursor对象等同于cursor: { batchSize: 0 }，即禁用游标
分片集群下聚合游标更危险：getMore必须打到同一个mongos
一旦用了cursor，getMore请求必须路由到最初执行aggregate的那个mongos节点，否则找不到缓存的ClusterClientCursor，直接报CursorNotFound。这要求客户端保持连接粘性，或通过负载均衡器配置session stickiness（如NGINX的ip_hash），否则看似启用了游标，实际第二轮就崩。
- 检查是否命中同一mongos：抓包看
getMore请求的Host头，或在mongos日志里搜getMore和CursorNotFound - 不要依赖客户端自动重试——
getMore失败后，原始聚合上下文已丢失，重试得重新发整个aggregate - Java驱动需确认
AggregateIterable是否调用了cursor(true)，Python的collection.aggregate(..., cursor={})参数不能漏
真要返回超大结果集？别拼成一个响应，改用流式导出或分批查
16MB限制本质是在提醒你：这个结果不该一次性传给应用。更稳的做法是让聚合只输出关键指标（如$group统计），或用$out写入临时集合再分页读；若必须导全量，用mongoexport或驱动的forEach流式消费，避免内存堆积和网络超时。
-
mongoexport --uri="mongodb://..." --collection=xxx --query="{...}" --out=data.json会自动按16MB切块写文件 - Node.js里用
cursor.stream()比toArray()安全，尤其配合pipeline里$limit或$sample预估数据量 - 如果聚合含
$lookup且被关联集合很大，先确认maxTimeMS够用，否则可能在游标生命周期内超时中断
