mongodb不支持防止幽灵读取的隔离级别，其事务仅提供read committed（行为近似快照隔离但不防幻读）；readconcern: "majority"仅保证读取已多数提交的数据，不锁定查询范围或维护谓词快照，故无法阻止幻读。
MongoDB 不支持防止“幽灵读取”（Phantom Reads）的隔离级别。它没有提供 Repeatable Read 或 Serializable 隔离级别，事务默认且唯一支持的是 Read Committed —— 实际行为接近快照隔离，但明确不防止幻读。
为什么 readConcern: "majority" 不能阻止幽灵读取
设置 readConcern: "majority" 只保证你读到的数据已写入大多数节点、不会被回滚，但它不锁定范围，也不维护查询谓词的快照边界。在事务中执行两次相同条件的 find()，中间若其他事务插入了匹配新文档并提交，第二次查询仍会看到该文档。
- 幽灵读取的本质是“新行插入”，而
majority关注的是“已有数据是否已持久化”，不是“查询结果集是否冻结” - 即使启用
enableMajorityReadConcern: true并配合事务，MongoDB 也不会对未命中的索引范围加锁或维护谓词级快照 - 分片集群下情况更复杂：跨片事务无法协调全局谓词视图，幻读概率进一步升高
事务内 readConcern 的实际作用范围
在 MongoDB 事务中，readConcern 仅控制“从哪个版本的数据快照读”，而非“读取哪些行”。它依赖 oplog timestamp 快照，但这个快照是事务开始时整个副本集的逻辑时间点，不包含 WHERE 条件的语义快照。
- 事务启动时获取一个 clusterTime，后续所有读都基于该时间点的 majority-committed 数据
- 但该时间点只锚定“哪些文档已提交”，不锚定“哪些文档满足
{ status: "pending" }这类条件在当时是否存在” - 所以如果另一事务在你事务执行期间插入了
{ status: "pending", createdAt: new Date() }，只要它在你事务的 clusterTime 之后提交，你就看不到；但如果它在之前提交——你就会在第二次查询中“突然出现”
能缓解幻读的替代做法（非根本解决）
没有银弹，但可在应用层收敛风险：
- 用唯一索引 +
upsert替代“先查后插”，避免业务逻辑依赖两次读的一致性 - 对关键范围加应用级锁（如 Redis 分布式锁），锁住
status = "pending"这一语义区间，代价是吞吐下降 - 改用单文档原子操作：把相关状态聚合进一个文档（例如用数组存 pending items），利用 MongoDB 单文档原子性规避跨文档幻读
- 接受幻读，在业务逻辑中做幂等或最终一致性校验（如支付场景用状态机+对账）
真正棘手的地方在于：错误地认为 readConcern: "majority" + 事务 = 关系型数据库的可重复读。它不是。MongoDB 的“快照隔离感”只来自时间戳对齐，而不是谓词锁定 —— 这个差异在高并发插入场景下会直接暴露。
