readConcern=“majority”并非设了就生效，需与writeConcern=“majority”、事务上下文及副本集状态对齐，否则可能读到回滚数据或过期视图；在非事务写入w:1、事务未配writeConcern、PSA滞后、偶数节点宕机等场景均会失效。
readConcern 不能靠“设了就生效”来保障一致性，它必须和 writeConcern、事务上下文、副本集状态三者对齐，否则读到的可能是回滚数据或过期视图。
readConcern=“majority” 为什么有时不生效
多数人以为只要设置 readConcern: "majority" 就能读到“已提交且不会回滚”的数据，但实际失效场景很常见：
- 在非事务操作中，
readConcern: "majority"确实能保证读取的数据已被大多数副本集节点持久化，但前提是写入时也用了writeConcern: "majority"；如果写入只用w: 1（仅主节点确认），那majority读可能根本看不到该写入——因为数据还没传播到多数节点 - 在事务中，
readConcern: "majority"的语义被弱化：只有当事务 提交时也带writeConcern: "majority"，该读关注才提供强保证；否则它退化为类似"local"的行为 - PSA（Primary-Secondary-Arbiters）架构下，若一个 secondary 滞后或不可达，
majority的“多数”可能卡在 2/3，导致读操作阻塞或超时，而非降级
什么时候该用 readConcern=“local”
"local" 是默认值，但它不是“不安全”的代名词，而是明确选择性能与可用性优先的策略：
- 读取最新写入（哪怕尚未复制）、容忍潜在回滚的场景，比如实时日志聚合、监控指标采集
- 单文档更新+读取组合（如计数器自增后立即读），因单文档原子性，
"local"仍能保证逻辑一致 - 分片集群中跨分片读取，
"majority"不被支持，只能用"local"或"available" - 注意：
"local"在主节点和从节点上行为一致，但返回的数据不保证存在于多数节点——故障转移时可能丢失
在 Rust 驱动中配置 readConcern 的关键点
Rust 驱动（mongodb crate）要求显式构造 ReadConcern 实例，且层级覆盖规则容易被忽略：
- 连接 URI 中指定
?readConcernLevel=majority仅影响客户端默认值，无法覆盖事务内显式设置 - 事务内必须用
session.start_transaction()的options参数传入ReadConcern::majority()，不能只靠 client 或 database 级别设置 - 使用
database_with_options()创建新Database实例时，ReadConcern只影响该实例发起的**非事务读操作**；事务内的读仍由事务选项决定 - 示例中常漏掉
.acknowledgment(WriteConcern::builder().w(Acknowledgment::Majority).build())配套，导致ReadConcern::majority()失去意义
最容易被忽略的兼容性陷阱
readConcern 的行为严重依赖 MongoDB 版本与部署拓扑：
- MongoDB 3.6+ 才正式支持
"majority"和"linearizable"；低于此版本设了也静默忽略 -
"linearizable"要求readPreference: "primary"且强制读主节点，否则报错；它还隐含maxTimeMS限制，超时即失败，不降级 - 副本集成员数为偶数（如 4 节点）时，“多数”是 3，但若一个节点宕机，剩下 3 个节点中只要再挂一个，
"majority"就不可达——这不是配置问题，而是拓扑风险 - 使用 Atlas 时，
"majority"的“多数”按物理节点算，但 Serverless 实例不支持该级别，会自动 fallback 到"local"，且无提示
