从评论：
唯一的问题是这个数字是否是累积的？是的，这就是问题所在。
不，您屏幕截图中的数字不是累积的。
您的屏幕截图来自Atlas分析器。the Atlas profiler documentation以及您对与getMore调用相关联的屏幕截图的引用都指向这样一个事实，即我们正在查看单个操作的结果。
与此相关的是，屏幕截图中的Response Length字段对应于操作的reslen。这也是单个调用传输的数据量。每批传输的数据量有16 MB的硬上限，因此返回的文档的大小会影响单批发送的数量。
然而，在做了我自己的研究之后，这个数字似乎是累积的。我对我的本地mongo数据库启动了一个监视，并对集合进行了更改，以查看运行db.currentOp（{ns：“{dbname}.$cmd”}）;会返回什么结果。nDocsReturned值似乎是对所做更新的数量进行计数。如果不是累积的，您如何解释？
谢谢你提供额外的上下文！你在这里看到的是“不同”的东西，这是混淆和错误结论的根源。
在这个接口中，被报告的对象是 cursor 本身。cursor是在执行查询（包括更改流）时创建的对象，它将返回多批数据。
正如您所正确得出的结论，此接口中的nDocsReturned度量对于游标是累积的。文档证实了这一点：
游标返回的文档的累积数。
紧接着，该页面还告诉我们关于nBatchesReturned：

currentOp.cursor.nBatchesReturned

游标返回的累计批数。
因此，每个 * 单独的getMore调用 * 都会添加到currentOp中可以观察到的这些 * 累积游标总数 * 中。但是日志文件和分析器只会报告与 * 单独的 * getMore执行相关的指标（这些指标在这些地方足够慢，可以报告）。
我们意识到我们没有做出那么多改变，
这听起来像是有比你预期的更多的更改，或者更改流比预期的更频繁地被（重新）打开（或者没有适当地使用“恢复后”功能）。