MongoDB 5.0 无原生流式插入API，所谓流式插入实为应用层基于 insertMany 和 BulkWrite 的封装；需控制批次大小（推荐100起）、设 ordered: false 保障连续性，并避免在事务中使用或调用已弃用的 insert() 方法。
MongoDB 5.0 本身不提供“流式插入”原语（比如像 insertStream 这样的 API），所谓“流式插入”实际是应用层基于批量写入机制 + 网络/内存缓冲做的模式封装，核心依赖的是 insertMany 和底层 BulkWrite 能力。
用 insertMany 模拟流式写入，但必须控制批次大小
直接把数万条文档塞进一个 insertMany 调用里，很容易触发 BSON 大小限制（16MB）或内存溢出。实际中应按固定 batch size（如 100–500 条）切分：
-
insertMany单次最多支持约 1000 条（取决于单文档平均体积），超过会报errmsg: "BSON object too large" - batch size 太小（如 10）会导致网络往返过多，吞吐下降；太大（如 2000）可能卡住连接或触发超时
- 推荐起始值设为 100，再根据实测 RT 和错误率调整
ordered: false 是流式场景的刚需配置
流式数据常含脏数据（如重复 _id、类型冲突），若用默认 ordered: true，一条失败整批中断，后续数据全积压——这违背“流”的连续性原则。
务必显式传参：
db.collection.insertMany(docs, { ordered: false })
-
ordered: false下失败项被跳过，其余继续执行，返回结果里writeErrors字段列出具体失败项 - 注意：即使 unordered，仍受单条文档校验约束（如
_id冲突仍报错，但不影响其他文档） - 不要在事务内用
ordered: false，MongoDB 5.0 不允许
避免用已弃用的 db.collection.insert()
mongosh 1.8+（MongoDB 5.0 默认配套）中 db.collection.insert() 已标记为 deprecated，且行为不一致：
- 传数组时实际调用的是旧版批量逻辑，错误处理粒度粗（只返回 success/fail，不细分哪条失败）
- 无法设置
ordered参数，也无法兼容现代驱动的writeConcern行为 - 升级到
insertMany后，错误对象结构统一，便于日志解析和重试逻辑编写
真正“流式”的边界在应用层，不在 MongoDB 服务端
MongoDB 5.0 的复制集 oplog 和 changeStream 是“流式消费”，不是“流式插入”。插入动作始终是离散的 RPC 请求。
如果真需要持续低延迟写入，关键点不在数据库命令，而在：
- 客户端是否启用连接池（driver 默认 poolSize=5，高并发下需调大）
- 是否复用
bulkWrite实例（避免反复创建 write model 对象） - 是否有背压控制（比如用 Node.js 的
stream.pipeline或 Java 的Flow.Subscriber控制上游吐速）
漏掉任何一环，都可能让“流式插入”变成内存泄漏或连接打满。
