MongoDB事务中bulkWrite报错的根本原因是不支持ordered:false且必须单集合操作；需强制ordered:true、统一writeConcern、避免跨集合，否则触发驱动层校验失败。
事务里调用bulkWrite为什么会报错
根本原因：MongoDB 事务不支持 bulkWrite 的 ordered: false 模式，且所有写操作必须在同一个集合内——但事务中实际执行的 bulkWrite 若混入跨集合操作、或显式传了 ordered: false，驱动会直接拒绝，抛出 MongoDB\Driver\Exception\BulkWriteCommandException 或类似错误。
常见错误现象包括：
-
BulkWriteCommandException提示 “ordered:false not allowed in transaction” - 事务中途
abort，日志显示 “write concern not satisfied” 或 “unavailable write concern” - 明明只操作一个集合，却报 “multi-namespace bulk write not supported in transactions”
关键限制有三点：
- 事务内
bulkWrite必须使用ordered: true（默认值），不能设为false；否则驱动层提前拦截 - 所有操作必须指向同一集合，不能像 8.0+ 的
db.adminCommand({ bulkWrite: ... })那样跨命名空间 -
writeConcern不能在bulkWrite调用时单独指定，必须在startTransaction时统一设置；否则被忽略或触发异常
事务中bulkWrite失败的典型场景
不是代码写错了，而是语义冲突了。比如你试图在事务里“先删旧数据、再插新数据”，但用了 ordered: false —— MongoDB 事务要求操作严格有序、可回滚，无序并行违背这个前提。
真实踩坑点：
- 把线上副本集的
bulkWrite配置（含ordered: false）直接搬进事务，结果一跑就崩 - 在事务里对
users集合做insertOne，又对logs集合做updateOne，即使都用ordered: true也报错 - 误以为
writeConcern: { w: "majority" }能在事务内 per-operation 设置，其实它只认事务启动时传入的writeConcern
怎么让事务里的bulkWrite真正跑起来
核心原则：退回到最保守、最兼容的模式。事务不是用来加速批量写的，而是保原子性；性能让位于一致性。
- 删掉所有
ordered: false，别加——事务里它本就不生效，加了反而触发校验失败 - 确保所有
operations数组里的操作，collection实例完全相同（不能是不同getCollection()返回的对象） - 写关注统一在
session.startTransaction({ writeConcern: { w: 1 } })里设，bulkWrite的options里不要传writeConcern - 如果真要处理重复键（比如导入去重），别靠
upsert或ordered: false，改用updateOne+upsert: true，并确保filter精确命中唯一索引字段
bulkWrite在事务里失败后怎么调试
别只看异常消息，重点查返回对象和 session 状态。
- 捕获
MongoDB\Driver\Exception\BulkWriteCommandException后，调用$e->getWriteErrors()—— 事务中它可能为空，说明失败发生在协议层，不是写入阶段 - 检查
$session->getTransactionState()：如果是"ABORTED"，说明已回滚，不能再继续用该 session - 用
mongosh手动复现：开启事务后，粘贴同一批operations，观察是否报Multi-namespace bulk write not allowed这类明确提示 - 确认驱动版本：PHP 驱动 bulkWrite 支持不全，升级常能解决隐性兼容问题
