事务中必须显式设置readConcern为"local"、"majority"或"snapshot"，且只能通过startTransaction()的TransactionOptions配置；"local"允许隐式建集合，"majority"需多数节点在线并启用journal，"snapshot"要求副本集或分片集群满足特定条件。
事务中必须显式设置读关注，不能依赖客户端或数据库级默认值；且只支持 "local"、"majority" 和 "snapshot" 三种级别。
事务级 readConcern 只能通过 TransactionOptions 设置
你无法在单个 find() 或 updateOne() 调用里传 readConcern 参数——事务内的读操作自动继承事务级别的设置。必须在调用 startTransaction() 时传入配置好的 TransactionOptions 实例。
- Java 驱动：用
TransactionOptions.builder().readConcern(ReadConcern.MAJORITY).build() - Node.js 驱动：传入
{ readConcern: { level: "majority" } }对象 - Python（pymongo）：用
session.start_transaction(read_concern=ReadConcern("majority")) - 直接在连接 URI 里设的
readConcernLevel不生效，事务会忽略它
不同 readConcern 级别的实际行为差异
"local" 是唯一允许隐式建集合/索引的级别；"majority" 要求数据已写入大多数节点才可见；"snapshot" 提供跨文档一致性快照，但仅在副本集和分片集群上可用（分片集群中还要求所有分片支持 majority journaling）。
-
"local"：最快，但可能读到后续回滚的数据；事务内创建集合必须用这个 -
"majority"：避免脏读，但有延迟；需确保副本集多数节点在线且启用 journal -
"snapshot"：多文档事务强一致性保障；分片集群中若任一分片禁用writeConcernMajorityJournalDefault，事务会直接失败
容易被忽略的兼容性限制
不是所有部署都支持全部级别——尤其要注意 "snapshot" 在分片集群中的硬性约束，以及 "majority" 对 journal 配置的依赖。
- 副本集启用
majorityreadConcern 前，必须运行rs.status()确认多数节点状态正常 - 分片集群中使用
"snapshot"，所有分片必须将writeConcernMajorityJournalDefault设为true（内存引擎节点不满足此条件） - 事务一旦开始，中间无法动态切换
readConcern；改级别必须结束当前事务并新开一个
事务里的 readConcern 不是“可选配置”，而是决定数据可见性和操作合法性的关键开关；设错会导致写失败、读脏、甚至整个事务被拒绝——尤其是建集合这类元操作，对 "local" 的依赖是刚性的。
