不能。MongoDB事务明确禁止db.createCollection()等DDL操作，因其无法记录于oplog、不可回滚，且会强制终止事务；隐式建集合在事务中也被禁用，所有集合必须预先存在。
事务里调用 db.createCollection() 会直接报错
不是语法写错，而是 MongoDB 明确禁止在事务上下文中执行任何 DDL 操作。db.createCollection() 属于数据库结构变更命令，和 drop()、createIndex()（带选项时）一样，无法被纳入事务日志（oplog）。一旦在 withTransaction() 回调或 session.startTransaction() 后的会话中调用它，驱动会立刻收到类似 Command not supported inside a transaction 的错误，事务状态也会被强制终止——后续语句不会执行，已做的 CRUD 操作也不会自动回滚（除非你手动捕获异常并调用 abortTransaction()）。
insertOne() 能自动建集合，但事务里也不行
平时用 db.mycol.insertOne({x:1}) 时，如果 mycol 不存在，MongoDB 会静默创建它。这个“隐式创建”机制在事务中被禁用。事务启动后，所有集合必须已存在且命名合规（不能是 temp_*、system.* 或以 $ 开头）。否则第一次访问该集合就会报 NamespaceNotFound，而不是帮你建一个。
- 事务内对集合的读写，都基于“集合已存在”的前提
- 所谓“自动创建”，本质是单文档写入时的副作用，而事务要求所有操作可回滚、可重放，隐式 DDL 破坏了这个契约
- 即使你在事务外用
insertOne()创建过集合，只要它没被显式createCollection()过，某些配置（如validator）可能未生效，事务里读写仍可能因 schema 验证失败而中断
为什么设计上必须这样隔离 DDL 和事务
MongoDB 的分布式事务依赖 oplog 实现跨分片一致性，而 oplog 只记录可回滚的 DML（insert、update、delete），不记录 DDL。如果允许事务内建集合：
- 某个分片上成功创建了集合，另一个分片因网络故障没收到指令，事务就无法达成多数派确认
- 回滚时，删掉一个刚创建的集合，会引发元数据不一致（比如索引残留、视图失效）
- 集群环境下，
createCollection()需要 config server 协调，而事务协调器（shard router）不参与 DDL 流程
所以这不是临时限制，而是架构级取舍：用 DDL/DML 分离换来了跨分片事务的可靠性。
真正要“原子性建集合+写数据”该怎么绕
没有银弹，只有适配场景的折中方案：
- 如果只是想确保“集合存在 + 初始数据写入”不被并发干扰：先在事务外
db.createCollection("orders", { validator: {...} })，再用事务写入第一批文档 - 如果需要切换结构（比如加 TTL 或改 clustered index）：用时间戳后缀建新集合（
orders_v20260721），事务写满后，在事务外db.orders.renameCollection("orders_old", { dropTarget: true })再db.orders_v20260721.renameCollection("orders") - 如果业务强依赖“空集合起步”，且能接受短暂不可用：事务外
drop()+createCollection()，再用事务写入；但必须确保这期间无其他会话读该集合，否则会看到NamespaceNotFound
最容易被忽略的一点：renameCollection() 是原子的，但它本身不支持事务，也不能跨数据库；一旦用了，就得把源和目标集合放在同一个 db 里，否则操作直接失败。
