错误码1780是MongoDB在使用多文档事务时可能出现的一个报错，完整提示通常是快照读隔离级别不支持这类信息。不少开发者在把单文档操作迁移到事务写法，或者在应用层配置了特定的隔离级别后第一次遇到它。这个报错本质上与MongoDB事务的隔离机制、版本能力以及会话配置密切相关，理解它的触发条件，才能从根源上解决问题。
错误码1780的触发原因分析
MongoDB的多文档事务从4.0版本开始引入，4.0只支持快照隔离，到4.2以及之后的副本集事务才开始支持可串行化快照隔离（通过writeConcern为majority的写和特定的读配置组合实现）。错误码1780最常见的触发场景是：客户端在会话或事务级别指定了一个当前MongoDB实例不支持的隔离级别组合。例如在较旧的版本上要求可串行化隔离，或者在事务中间尝试更改读关注级别，都会被服务端拒绝并返回1780错误。
另一个常见原因是驱动层的配置冲突。有些ORM框架（比如Spring Data MongoDB的早期版本）在事务模板中显式传入了isolation参数，而MongoDB Java驱动并不支持像关系型数据库那样自由设置隔离级别，一旦传入不兼容的值，驱动在和服务端协商事务选项时就会失败。此外，如果事务的readConcern设置为snapshot以外的值，而在事务已经开始后又尝试用不兼容的方式读取，也可能触发类似错误。
还有一种容易被忽视的情况：分片集群与副本集对隔离级别的支持不完全一致。某些读关注和写关注的组合在分片集群上要求所有节点版本达标，如果集群中混有旧版本节点，事务快照的协调就会失败。排查时可以先确认集群版本一致性。
读关注级别与事务快照的关系
要理解1780错误，必须先弄清MongoDB事务中的读关注概念。事务中默认使用readConcern为snapshot，表示事务内所有读操作都基于事务开始时刻的数据快照，读到的数据在整个事务期间保持一致视图。这就是MongoDB的快照隔离：事务看不到其他事务在开始之后提交的修改。
快照隔离能防止脏读和不可重复读，但无法完全防止写偏序。MongoDB在较新版本中通过writeConcern为majority的写冲突检测机制，在快照隔离基础上提供了接近可串行化的保证。如果应用代码按照关系型数据库的习惯去显式声明SERIALIZABLE隔离级别，MongoDB驱动没有对应的实现，就可能在选项协商阶段抛出1780错误。正确的做法是依赖默认的snapshot读关注，而不是强行指定隔离级别枚举值。
下面是一段典型的问题代码和修正后的写法，以Java驱动为例：
// 错误写法：显式指定关系型数据库风格的隔离级别
TransactionOptions options = TransactionOptions.builder()
.readConcern(ReadConcern.SNAPSHOT)
.writeConcern(WriteConcern.MAJORITY)
.build();
// 如果同时又在会话上设置了不兼容的选项，服务端可能返回错误1780
// 正确写法：事务中依赖快照读关注，不额外指定隔离级别枚举
ClientSession session = client.startSession();
session.startTransaction(TransactionOptions.builder()
.readConcern(ReadConcern.SNAPSHOT)
.writeConcern(WriteConcern.MAJORITY)
.build());
try {
MongoCollection<Document> coll = db.getCollection("orders")
.withReadConcern(ReadConcern.SNAPSHOT);
coll.find(new Document("status", "pending")).first(session);
session.commitTransaction();
} catch (Exception e) {
session.abortTransaction();
} finally {
session.close();
}注意代码中集合级别和事务级别的读关注必须保持一致，混用不同readConcern是诱发1780错误的常见写法问题。事务一旦开始，读关注级别就固定了，中途更改必然失败。
解决方法与排查步骤
遇到1780错误时，建议按以下顺序排查。第一步检查MongoDB版本，事务相关能力对版本要求较高，副本集事务需要4.0以上，分片集群事务需要4.2以上，可串行化快照隔离相关的特性更是要求更高的版本。如果版本过低，升级是唯一可靠的解决途径。
第二步检查事务启动代码。确认没有在startTransaction之后修改会话选项，确认集合和事务使用相同的readConcern。如果使用Spring框架，检查Transactional注解或TransactionTemplate上是否设置了数据库无关的isolation属性，将其移除即可。Spring Data MongoDB的事务不需要也不能设置隔离级别，框架会自动采用snapshot。
第三步检查集群部署形态。单节点副本集可以支持事务，但某些读关注（例如majority）需要启用副本集并且成员数满足条件。可以用下面的命令确认节点状态和版本：
# 查看副本集成员状态
rs.status()
# 查看服务端版本
db.version()
# 确认当前节点的读关注支持情况
db.runCommand({ connectionStatus: 1, showPrivileges: false })第四步检查驱动版本与服务器版本的兼容性。旧驱动对新服务端的事务选项协商可能存在问题，升级驱动到与服务器版本匹配的发布线，很多1780类报错在驱动升级后自动消失。
常见误区与注意事项
第一个误区是把MongoDB当成关系型数据库来配置隔离级别。MongoDB没有READ UNCOMMITTED、READ COMMITTED这样的传统隔离级别枚举，它的隔离控制是通过readConcern和writeConcern组合实现的。任何试图传入传统隔离级别参数的代码都是错误的，无论数值还是字符串形式。
第二个误区是忽略事务中的冲突处理。即使配置正确，快照隔离下的事务在提交时仍可能遇到写冲突（错误码112），应用层必须实现重试逻辑。MongoDB驱动的回调式事务API已经内置了针对瞬时错误的重试，推荐优先使用：
// 回调式事务API，驱动自动重试瞬时错误
client.startSession().withTransaction(() -> {
MongoCollection<Document> coll = db.getCollection("orders");
coll.updateOne(session, new Document("_id", 1),
new Document("$set", new Document("status", "paid")));
return null;
}, TransactionOptions.builder()
.readConcern(ReadConcern.SNAPSHOT)
.writeConcern(WriteConcern.MAJORITY)
.build());第三个注意事项是事务不宜过长。快照隔离依赖快照的持有时间，事务时间越长，持有锁和缓存快照的开销越大，冲突概率也越高。官方建议单个事务的执行时间控制在60秒以内，操作数量不超过1000次。合理拆分业务逻辑，避免在大事务中做复杂计算，是保证事务稳定运行的基础。
总结来说，错误码1780的核心在于隔离级别与MongoDB事务能力不匹配。排查思路是：先确认版本满足要求，再检查代码中是否错误地指定了隔离级别或混用了readConcern，最后保证驱动与服务器版本配套。遵循默认的snapshot读关注，使用回调式事务API并配合合理的重试策略，绝大多数1780报错都能被彻底解决。