insertmany默认ordered:true导致中间失败即中断，非本身慢；应设{ordered:false}跳过错误项，调优writeconcern和分批（≤10万条/批、总bson≤16mb）以提升性能。
insertMany 为什么比循环 insertOne 慢？
不是 insertMany 本身慢，而是默认开启了有序执行（ordered: true），一旦中间某条文档插入失败（比如重复键冲突），后续所有文档都会被跳过。这在调试时容易误判为“批量失败”，实际只是被中断了。
常见错误现象：BulkWriteError 报错但只看到第一条失败原因，其余插入结果不可见；或数据量大时耗时远超预期——往往是因为没关掉写关注（writeConcern）或没调优连接池。
- 用
{ ordered: false }允许跳过失败项继续执行，适合脏数据容忍场景 - 显式设置
writeConcern: { w: 1 }可避免默认的{ w: "majority" }带来的同步等待 - 单次
insertMany不宜超过 10 万条文档，否则可能触发 BSON 限制（16MB）或内存溢出
如何避免 BSON size limit 错误？
insertMany 提交的整个数组会被序列化为一个 BSON 对象，总大小不能超过 16MB。这不是每条文档限制，而是整批请求上限。遇到 Document too large for insert 就得拆分。
实操建议：
- 用
Buffer.byteLength(JSON.stringify(doc), 'utf8')预估单条体积，留 20% 余量后计算批次大小 - 不要依赖
chunkSize硬拆——按字节而非条数切更可靠，尤其文档长度差异大时 - Node.js 中可用
stream.Transform边读边 chunk，避免一次性加载全部数据到内存
insertMany 后怎么拿到成功插入的 _id？
insertMany 返回值里的 ops 数组和原始输入顺序一致，但只有成功插入的文档才有 _id 字段。如果用了 { ordered: false }，失败项不会出现在 ops 中，但你无法直接对应到原数组索引。
正确做法：
- 插入前给每条文档加唯一临时标记（如
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，容易超时或锁表 - 开启事务前确认副本集配置支持事务（需 v4.0+，且 storage engine 是 WiredTiger）
真正影响效率的从来不是方法名，而是你有没有在插入前删掉那个没用的 ensureIndex 调用，或者忘了关掉日志级别的 slowms 设置。
