不能。MongoDB事务不支持drop或createCollection等DDL操作，因其仅覆盖已存在集合的CRUD操作；DDL属数据库级命令，无法记录于oplog、不可回滚，且执行会强制退出事务。
不能。MongoDB 事务不支持 drop 或 createCollection 这类 DDL 操作。
为什么事务里删不了集合又建不了新集合
MongoDB 的多文档事务（从 4.0 开始支持）只覆盖 CRUD 操作，且仅限于已存在的集合。所有涉及集合结构变更的操作——比如 db.collection.drop()、db.createCollection()、db.runCommand({ create: "..." })——都属于 DDL，被明确排除在事务上下文之外。
尝试在事务中执行会直接报错：Transaction numbers are only allowed on operations that support them 或更直白的 Command not supported inside a transaction。
-
drop()和createCollection()是数据库级命令，不是集合级操作 - 事务日志（oplog）不记录 DDL，无法回滚结构变更
- 即使使用
mongosh或驱动开启 session，一旦调用drop()就会立刻退出事务上下文
想“原子性重置集合”该怎么做
没有真正的原子方案，但有接近效果的替代路径，取决于你的实际目标：
- 如果目标是清空并重填数据：用
deleteMany({})+insertMany()，都在事务内完成 —— 数据干净、可回滚 - 如果必须重建集合（比如改了 validator、collation 或 clustered index）：先在事务外
drop()，再createCollection()，最后用事务写入初始数据 —— 结构和初始数据可保证一致，但中间存在“集合不存在”的窗口期 - 如果怕并发读到空状态：给集合起临时名（如
users_v2），写完再用renameCollection()替换旧集合 ——renameCollection本身不支持事务，但它是原子的，且阻塞读写，比 drop+create 更安全
容易踩的坑
很多人以为用 withTransaction() 包一层就能搞定所有操作，结果在生产环境触发不可逆失败：
- 在事务回调里调用
db.mycol.drop()，事务自动终止，后续插入不会回滚，但集合已经没了 - 误以为
createCollection能在事务里延迟生效，实际它立刻执行并抛异常，导致回调提前退出 - 用
renameCollection时没加{ dropTarget: true }，目标集合存在则失败，而不是覆盖 —— 这个选项必须显式传 - 集群环境下（sharded cluster），
renameCollection不支持跨分片库，且要求源和目标在同一个数据库中
真正难的不是语法，而是把“重建集合”这个业务意图拆解成 MongoDB 实际能保障的边界操作。DDL 和 DML 的隔离是硬限制，绕不开，只能适配。
