MongoDB单机模式不支持readConcern: "snapshot"，因该级别硬性依赖副本集oplog机制；必须部署为副本集（如单成员rs.initiate）并显式在withTransaction()第二参数中传入{ readConcern: { level: "snapshot" } }才生效。
ReadConcern "snapshot" 报错：Snapshot reads require a replica set
单节点 MongoDB 实例不支持 readConcern: "snapshot"，这是硬性限制，不是配置问题。报错信息里明确写着 Snapshot reads require a replica set，说明你正在用 standalone 模式跑事务却试图启用快照读。
常见误操作是本地开发时直接启动 mongod --port 27017，没搭副本集，然后在代码里传了 { readConcern: { level: "snapshot" } } —— 这会直接 throw Error，事务根本不会执行。
- 验证方式：连接后运行
rs.status()，如果报no replset config或返回空对象，就是 standalone - 临时解决（仅开发）：改用
readConcern: "majority"，但需确保副本集已启用enableMajorityReadConcern: true - 生产必须用副本集（哪怕三节点 PSA 架构），初始化命令示例：
rs.initiate({ _id: "rs0", members: [{ _id: 0, host: "localhost:27017" }] }) - 注意：Docker 部署时，
docker run命令要加--replSet rs0参数，且首次启动后必须手动rs.initiate()
事务内读不到刚写入的数据：readConcern 没传到 withTransaction
最常被忽略的坑：把 readConcern 错误地塞进 insertOne() 或 findOne() 的 options 里，而不是传给 withTransaction() 的第二个参数。MongoDB 完全忽略前者，仍用默认的 "local"。
现象是：事务里先 insertOne({ x: 1 })，紧接着 findOne({ x: 1 }) 返回 null —— 不是异步问题，是读关注没生效。
- 错误写法：
await collection.insertOne({ x: 1 }, { readConcern: { level: "snapshot" } }) - 正确写法：
await session.withTransaction(async () => { ... }, { readConcern: { level: "snapshot" } }) - Mongoose 用户注意：v6.0+ 才真正支持该选项；旧版即使写了也静默失效
- 所有事务内读操作（
find、countDocuments、aggregate）都自动继承这个readConcern，无需重复设置
分片集群事务失败：各分片 readConcern 配置不一致
跨分片事务要求所有 shard 必须统一启用 readConcern: "majority"，且 enableMajorityReadConcern 全局开启。任意一个分片不达标，事务会在 prepare 阶段静默失败，日志里只显示模糊的 NotMasterOrSecondary 或超时。
典型场景：测试环境用单副本集，生产切分片后没同步配置，或者滚动升级时部分分片版本落后（如 5.0.15 和 5.0.20 混用）。
- 逐个检查每个 shard 的 primary：
db.runCommand({ getCmdLineOpts: 1 })，确认parsed.enableMajorityReadConcern === true - 运行
rs.status()，确保所有成员状态为PRIMARY或SECONDARY，且optimes.lastCommittedOpTime接近 - 执行
db.version()和db.runCommand({ buildInfo: 1 })，比对小版本号和gitVersion是否完全一致 - config server 副本集必须最先升级，否则新旧协调逻辑不兼容，触发
UnknownTransactionCommitResult
PSA 架构高并发下 readConcern: majority 导致延迟飙升
三节点 PSA（Primary-Secondary-Arbiter）架构下，启用 readConcern: "majority" 会在 secondary 宕机时引发严重性能退化——WiredTiger 缓存压力剧增，读写延迟可飙至 10 分钟以上。
这不是 bug，是官方明确警告的设计约束（4.2–4.4 版本）。问题只在高并发（>1k QPS）+ 副本集降级时暴露，低流量下完全正常。
- 临时缓解：停用 majority 读关注，改用
readConcern: "local"，但需接受可能读到回滚数据的风险 - 长期方案：升级到 MongoDB 5.0+，引擎层优化后该参数不再可配，强制为 true 且无此副作用
- 注意：Arbiter 节点不参与多数派投票，PSA 实际只有两个数据节点，secondary 宕机即丧失 majority 能力
- 若必须保强一致性，应改为 PSS（Primary-Secondary-Secondary）架构，避免 Arbiter
