mongodb默认可能读到未提交的数据，因其事务隔离依赖readconcern配置而非自动隔离级别；未设readconcern: "majority"时，副本集或分片集群中可读取未提交的中间状态，导致脏读。
MongoDB 4.0+ 支持多文档 ACID 事务，但默认不提供可重复读（Repeatable Read）语义，脏读在某些场景下确实可能发生 —— 尤其在复制集或分片集群中未显式配置读关注（readConcern）时。
为什么 MongoDB 默认可能读到未提交的数据
MongoDB 的事务隔离行为高度依赖 readConcern 和 writeConcern 配置，而非像传统 SQL 那样靠“隔离级别”开关控制。它的“读已提交”能力不是自动开启的：
- 单机或副本集主节点上执行读操作，若未指定
readConcern: "majority"，可能读到其他事务尚未提交、但已写入 majority 节点的中间状态（即“脏读”） - 即使使用
readConcern: "majority"，也无法完全避免不可重复读：同一事务内两次find()可能因其他事务提交而返回不同结果，因为 MongoDB 不锁定读取范围（无 gap lock 或 range lock） - 分片集群中情况更复杂：协调器（mongos）不保证跨分片事务的全局快照一致性，
readConcern: "majority"仅作用于单个分片，无法覆盖整个事务视图
必须设置 readConcern: "majority" 才能防止脏读
这是最直接有效的防线。不设它，事务外的读（包括事务内对其他集合的读）都可能看到未提交变更：
- 在启动会话时显式传入：
session.startTransaction({ readConcern: { level: "majority" } }) - 驱动版本需 ≥ 4.2（Node.js 驱动），且 MongoDB 服务端 ≥ 4.0；旧版驱动可能忽略该选项
- 注意：
readConcern: "majority"要求副本集多数节点已确认写入，会略微增加延迟；若多数节点不可用，读操作将阻塞或失败 - 不能只在客户端连接字符串里配
readConcern—— 事务内所有读操作继承事务级readConcern，必须在startTransaction()中声明
不可重复读无法靠配置彻底消除，只能靠设计规避
MongoDB 没有可重复读（Repeatable Read）级别的原生支持。即使开了 readConcern: "majority"，以下情况仍会发生不可重复读：
- 事务 A 执行
db.orders.find({ status: "pending" })→ 得到 5 条 - 事务 B 提交了新订单并更新某条 pending 订单为 "shipped"
- 事务 A 再次执行同一条
find()→ 可能返回 4 条（少了一条）或 6 条（多了一条） - 原因：MongoDB 不对查询条件加范围锁，也不维护事务开始时的全局快照视图
实用对策：
- 把关键业务逻辑收束进单次读+写组合，例如用
findOneAndUpdate()原子地查改，避免“读-判断-再写”流程 - 对需要强一致性的聚合结果，改用
$lookup+$match在单次聚合中完成，减少多次读的窗口 - 接受最终一致性，在应用层加版本号（
version字段）或时间戳校验，写前比对是否被其他事务修改过
分片集群下脏读风险更高，需额外约束
分片环境下，readConcern: "majority" 仅保障单一分片内读已提交，跨分片事务无法提供统一快照：
- 事务涉及多个分片时，每个分片独立提交，协调器不保证所有分片在同一逻辑时间点可见
- 若一个分片已提交、另一个尚未，外部读可能看到部分生效的状态（即“分布式脏读”）
- 目前唯一缓解方式是：确保事务只操作单一分片上的数据（即所有文档共享相同分片键值），这样
readConcern: "majority"才真正有效 - 避免在事务中执行跨分片的
distinct()、countDocuments()等操作；它们不支持分片事务，会被拒绝或降级为非事务行为
真正难处理的从来不是“怎么设参数”，而是当业务假设“两次读结果一致”时，MongoDB 并不保证这一点 —— 它的事务模型面向的是“原子性+已提交可见性”，不是传统 SQL 的强隔离。任何依赖可重复读的逻辑，都得在应用层兜底。
