listCollections 不支持在事务中执行是设计限制而非 bug，因元数据操作与事务的 snapshot 隔离模型冲突，必须在事务外完成集合存在性检查等前置动作。
listCollections 不在事务支持列表里，不是 bug 是设计限制
从 MongoDB 4.0 引入多文档事务起，listCollections 就被明确排除在事务允许操作之外。这不是驱动或版本适配问题，而是服务端硬性拒绝——事务上下文里调用它，直接抛 OperationNotSupportedInTransaction。根本原因在于：事务聚焦于「数据变更的原子性」，而 listCollections 属于元数据发现类命令，不修改数据但依赖全局一致的 catalog 视图，与事务的 snapshot 隔离模型冲突。
事务中调用 listCollections 的典型报错和触发场景
错误信息固定为：OperationNotSupportedInTransaction: Cannot run 'listCollections' in a multi-document transaction。常见触发点包括：
- 在 Node.js 驱动中，误在
session.withTransaction()回调内调用db.listCollections().toArray() - 用 PyMongo 时，在
with client.start_session() as s:块里执行db.list_collection_names() - Java 驱动中，对
ClientSession绑定的MongoDatabase调用listCollections()
绕过事务执行 listCollections 的安全做法
必须把元数据操作移出事务边界。关键原则是：事务只管「数据读写」，集合存在性检查、结构探测等前置动作全在事务外完成。
- 先用独立连接或未绑定 session 的
db实例调用listCollections，确认目标集合存在且可写 - 再启动事务，仅执行
insertOne、updateOne等受支持操作 - 如果需动态判断集合是否存在（比如 upsert 场景），改用
db.runCommand({ listCollections: 1, filter: { name: "target" } })—— 该命令本身不能进事务，但可在事务前安全执行 - 避免在事务中做任何
createCollection、dropCollection或collectionExists类 DDL 判断，这些同样不被支持
容易被忽略的兼容性陷阱
即使你没主动调用 listCollections，某些封装方法可能暗地触发它：
-
db.collection.countDocuments()在分片集群上若集合不存在，底层可能尝试探测，导致事务失败 - 部分 ODM（如 Mongoose）的
Model.init()或连接初始化逻辑会自动调用listCollections，务必确保它们不在事务 session 中运行 - mongosh 的
show collections或db.getCollectionNames()是 shell 辅助命令，本质仍走listCollections，绝不可放在session.startTransaction()之后
真正需要事务保障的永远只是那几行增删改查；所有“看看有没有这个集合”“这个字段存不存在”的动作，都得提前干完，别塞进事务里。
