Read Concern Majority 不能保证已提交读，因其依赖 oplog 中多数节点确认的 MCP 点，而事务提交与 MCP 更新存在异步延迟；事务刚提交后立即 majority 读可能读不到新值，甚至读到旧值。
Read Concern Majority 为什么不能保证已提交读
很多人以为 readConcern: "majority" 就等同于“只读已提交的数据”，实际不是。MongoDB 的 majority 读关注依赖的是 oplog 中的 majority committed point（MCP），而事务提交和 MCP 更新之间存在延迟——事务写入先落盘到 WiredTiger，再异步刷到 oplog，最后才被多数节点复制并推进 MCP。因此，在事务刚 commitTransaction 返回成功后，立刻用 readConcern: "majority" 去读，仍可能读不到自己刚写的值，甚至读到旧值。
常见错误现象：write concern: "majority" + readConcern: "majority" 组合下，应用层看到“写成功但读不到”，误判为数据丢失或事务失败。
- 根本原因不是 bug，而是 MongoDB 对“已提交”的定义基于复制状态，而非本地事务状态
- 该行为在分片集群中更明显，因为 config server 和 shards 的 MCP 同步有额外延迟
- 若需强读己写（read-your-writes），必须搭配
session.startTransaction()后的 session 级读，且读操作也需在同一 session 中发起
Local 读关注在事务中的真实语义
readConcern: "local" 在事务中不等于“读未提交”——它读的是当前节点上最新可用的、尚未被多数确认的数据，但受事务隔离约束：同一会话内，它能看到本事务已写入但尚未 commit 的文档（即支持脏读本事务），但看不到其他事务未提交的变更（其他事务的写对它是不可见的）。
使用场景有限但关键：
- 调试时快速验证本事务中间状态（比如批量更新中途检查计数器）
- 与
writeConcern: "majority"搭配做最终一致性预估（例如日志记录写入后立即 local 读，不等待复制） - 在单节点部署或测试环境绕过复制延迟，加速开发迭代
注意：readConcern: "local" 在分片集群中可能跨 shard 读到不同时间点的数据，不保证因果顺序。
事务中 Read Concern 的强制约束条件
MongoDB 要求：事务内的所有读操作必须使用与事务启动时一致的 readConcern；不能在事务中动态切换，也不能混用 "local" 和 "majority"。否则驱动会报错 InvalidOptions: readConcern cannot be changed within a transaction。
更隐蔽的限制：
- 如果事务开启时没显式指定
readConcern，默认继承客户端连接的配置；若连接未设，则 fallback 到"local"（4.0+ 默认行为） - 在副本集上启用
readConcern: "majority"前，必须确保storage.journal.enabled: true且enableMajorityReadConcern: true已在 mongod 启动时配置，否则会拒绝事务启动 - 分片集群中，
readConcern: "majority"仅在sharding.version: 5.0+且所有 shard 运行 4.2+ 时才完全支持事务级语义
选 Local 还是 Majority？看这三点
别凭直觉选，按实际一致性需求和部署结构判断：
- 需要跨会话强一致性（如订单支付后客服系统立刻查到）→ 必须
readConcern: "majority"，并接受最多几百毫秒延迟 - 事务内仅需读自己写的中间结果（如库存扣减 + 订单生成 + 日志落库）→
readConcern: "local"更快、更可控 - 集群未开启
enableMajorityReadConcern或使用旧版本 WiredTiger →"majority"会被静默降级为"local"，此时日志里会有 warning，但应用无感知
最容易被忽略的一点：即使你写了 readConcern: "majority"，如果事务跨越了分片迁移窗口（chunk move in progress），读操作可能被路由到尚未同步完的旧 shard，导致短暂读到空或陈旧数据——这不是 read concern 的问题，而是分片元数据刷新延迟所致。
