先给出结论：insertMany 本身并不慢，真正拖慢性能的往往是默认的 ordered: true 设置。一旦中间某条文档插入失败（例如重复键冲突），整个批处理会立即中断，后续文档全部被跳过。很多开发者调试时遇到 BulkWriteError 报错，误以为整批都失败了，实际上只是被“有序模式”截断了。
insertMany 为什么比循环 insertOne 慢？——有序模式是主要瓶颈
说实话，不是 insertMany 本身慢，而是它的默认行为——有序执行（ordered: true）在作祟。一旦中间某条文档出现键冲突等异常，后续所有文档会立即被停止。数据量大时尤其棘手：你以为整批都失败了，其实只是被中断，其余插入结果根本看不到。
常见的错误表现包括：看到 BulkWriteError 报错，但只显示第一条失败原因，其余的都石沉大海；或者数据量一大，耗时远超预期——实际上，问题往往出在未关闭写关注（writeConcern）或连接池调优不足上。
- 关键一招：启用
ordered: false，允许跳过失败项继续执行，特别适合容忍脏数据的场景。 - 写关注别拖后腿：显式设置
writeConcern: { w: 1 }可避免默认{ w: "majority" }带来的全局同步等待，性能提升立竿见影。 - 批次大小要克制：单次
insertMany不要超过 10 万条文档，否则容易触发 BSON 限制（16MB）或内存溢出，得不偿失。
如何避免 BSON 大小限制错误？
insertMany 提交的整个数组会被序列化为一个 BSON 对象，总大小必须控制在 16MB 以内。这不是单条文档的限制，而是整批请求的上限。遇到 Document too large for insert 错误时，必须进行拆分。
实际操作建议：
- 提前量很重要：使用
Buffer.byteLength(JSON.stringify(doc), 'utf8')预估单条体积，并留出 20% 的余量再计算批次大小，比拍脑袋更可靠。 - 按字节切分更可靠：不要依赖
chunkSize硬拆，尤其文档长度差异大时，按字节比按条数更准确。 - 流式处理省内存：在 Node.js 中，可以使用
stream.Transform边读取边分块，避免一次性加载全部数据到内存。
insertMany 后如何获取成功插入的 _id？——正确做法与注意事项
insertMany 返回的 ops 数组虽然与原始输入顺序一致，但只有成功插入的文档包含 _id 字段。如果使用 { ordered: false }，失败项不会出现在 ops 中，你也无法直接通过它定位原数组索引。
正确做法：
- 加个临时标记：插入前为每条文档添加唯一的临时 ID，例如
tempId: Math.random()，失败后从result.getWriteErrors()中提取index找回原数据。 - 别盲目依赖返回值：如果需要“插入后立即查询新 _id”，不要依赖返回值，直接使用
find({ _id: { $in: insertedIds } })进行二次确认更稳妥。 - 注意驱动版本差异：MongoDB 驱动版本不同，
result.insertedCount和result.upsertedCount的含义有所差异，v4+ 才统一支持insertedIds字段。
事务中能否使用 insertMany？——约束与风险
可以使用，但前提是：所有文档必须满足事务的约束，例如唯一索引、引用完整性，并且整个事务内的操作总大小仍然受 16MB 限制。更大的风险在于，事务中 insertMany 失败会导致整个事务回滚，无法像非事务模式那样通过 ordered: false 进行局部容错。
使用场景很有限：
- 只适合强一致性要求且数据量较小的场景。
- 不要在事务中混用
insertMany和大量updateOne，容易导致超时或锁表。 - 开启事务前，确认副本集配置支持事务（需要 MongoDB v4.0+，存储引擎为 WiredTiger）。
归根结底，真正影响效率的从来不是方法名，而是你是否在插入前删除了无用的 ensureIndex 调用，或者是否忘记了关闭日志级别的 slowms 设置。
