PHP MongoDB 事务提交后仍然查到旧数据，常见原因通常不是事务失效，而是查询没有绑定同一个 session，或者没有设置 readConcern: "majority"；在 PHP 驱动中，所有 find 查询都必须显式传入 session 参数，否则就会按普通读取处理，无法参与事务隔离。
事务提交后查询到旧数据，并不代表 MongoDB 事务没有生效，而是你当前读取的结果并不是事务写入后的那份数据——最常见的情况是查询条件没有命中刚被更新的文档，或者读操作没有绑定到事务会话中。
PHP 驱动里不传 session 参数，查询就不会进入事务上下文
在 PHP 的 MongoDB 驱动（mongodb/mongodb）中，有一个非常容易忽视、但对事务读写结果影响极大的细节：每一次数据库操作都必须显式携带 session。否则，驱动会将其当作普通查询执行，这样就不会享受事务隔离。即使代码写在 withTransaction() 回调内部，只要 find() 调用时没有传入 session，这次读取依然会被识别为独立的非事务读操作。
collection->find(['status' => 'done'])→ 普通读取，可能看到事务提交前的旧状态collection->find(['status' => 'done'], ['session' => $session])→ 事务内读取，可以看到当前事务刚写入的最新变更
需要特别注意：这里的 session 必须是同一个会话对象，不能在事务回调外重新创建，也不能误用其他 session 实例。
事务提交后立刻查询，却没有设置 readConcern 或级别设置不正确
MongoDB 默认使用的是 readConcern: "local"。在事务提交之后，其他客户端（包括你自己后续发起的查询）可能因为副本复制延迟或读取关注级别不同，暂时无法看到最新提交的数据。尤其是在副本集环境下，主节点虽然已经完成提交，但从节点可能还没有同步完成。
- 如果想确保查询读到的是已经提交并对多数节点可见的结果，就需要显式设置
readConcern: "majority" - 同时也要知道：
"majority"需要多数节点确认，因此会带来额外延迟；如果集群本身没有启用majoritywrite concern，那么这个设置也不会真正生效 - PHP 中常见写法：
$collection->find($filter, ['readConcern' => new ReadConcern('majority')])
查的是另一个集合，或者查询字段根本没有被事务修改
MongoDB 事务只保证事务内部写入数据的原子性与隔离性，并不会影响那些根本没有参与事务的数据。实际排查中，下面这些误判场景非常常见：
- 事务里更新的是
orders集合中的status，但你却去users集合查询name—— 两者本身就没有关联 - 事务更新时使用了
$set，但查询条件写成了{ status: { $ne: null } }，而该字段原本就是null，实际结果并没有变化 - 使用了
upsert: true，但匹配条件没有命中任何旧文档，最终是插入了一条新的 doc，你却仍然按照旧 id 去查询
PHP 进程中混用了不同连接或不同数据库实例
如果你使用的是 Laravel 或者自定义数据库封装，就很容易出现这种问题：事务执行时使用的是一个 $db 实例，提交后查询时却换成了另一个没有绑定 session 的 $db2。MongoDB PHP 驱动不会自动把 session 挂载或“粘附”到连接池上，因此每一次操作都需要手动透传 session 参数。
- 检查所有
find/findOne调用是否都显式传入了['session' => $session] - 尽量避免全局复用
Collection对象：事务内部应从同一个Database实例获取 collection，并始终传递同一个 session - 不要在事务回调外再调用
$collection->findOne()—— 因为此时$session很可能已经结束，或者已不再可用
这个问题最难排查的地方在于：PHP MongoDB 驱动通常不会直接报错，它只是悄无声息地执行了一次普通查询。真正需要重点检查的，不是事务块是否成功 commit，而是每一条 find、findOne 查询是否都正确携带了事务 session 参数以及合适的读关注级别。
