MongoDB事务中readPreference必须为primary，否则报错；因事务需因果一致性，所有读写须在同一主节点执行以保证原子性与隔离性，secondary存在延迟且破坏快照一致性。
事务中设置 readPreference 会直接报错
MongoDB 事务要求所有操作必须路由到同一个节点（通常是主节点），因此在开启事务的会话中调用 session.withTransaction() 或手动调用 session.startTransaction() 后，再执行类似 collection.find().readPreference('secondary') 这类操作，驱动会立即抛出错误：Read preference in a transaction must be primary。
这不是驱动的限制，而是 MongoDB Server 4.0+ 的强制校验。事务上下文里，Server 会拒绝任何非 primary 的 readPreference 请求，哪怕你只是想读——因为读操作也必须和写操作发生在同一份数据视图（即主节点的最新 oplog 位置）上，否则可能破坏事务的原子性与一致性。
- 即使只读不写，只要在事务会话内，
readPreference就不能设为'secondary'、'nearest'等 - 显式传入
{ readPreference: 'primary' }是冗余但合法的；不传则默认使用会话级的primary - Node.js 驱动中，
session.getDatabase().collection('x').find(...)继承的是会话的读偏好，不是客户端或连接池的全局设置
为什么主节点是唯一安全选项
事务依赖单一会话的“因果一致性”保障：所有读写必须基于同一个复制集成员的最新状态，且该成员必须能接受写入（即主节点）。Secondary 节点存在复制延迟，其数据快照可能落后于主节点当前事务已修改但尚未提交的部分，导致读取到过期值或违反隔离级别（如不可重复读）。
更关键的是，MongoDB 事务的两阶段提交（2PC）协议由主节点协调，所有参与者（包括主节点自己）都通过该节点同步 prepare/commit 状态。如果允许从 secondary 读，就等于绕开了协调者的数据视图，事务引擎无法保证读操作看到的是“事务内一致的快照”。
- 事务中的
find()实际走的是主节点的 snapshot 读，而非普通读；这个 snapshot 由事务开始时的lsid+txnNumber锁定 - 试图在事务中切换
readPreference，等价于让一次事务跨多个数据版本，Server 层直接拦截，不进入查询执行阶段 - 副本集配置里的
slaveOk: true或连接字符串中的readPreference=secondary对事务会话完全无效
常见误用场景与替代方案
开发者常因性能或负载分散意图，在事务里尝试降级读请求，结果触发报错或隐式失败。典型误用包括：在事务回调中调用带 readPreference 的聚合、用 collection.aggregate().readPreference('secondary') 做中间计算、或复用已有带偏好配置的 collection 实例。
- 不要在事务回调函数里新建带非
primary偏好的 collection：驱动不会自动覆盖，会沿用你创建时的配置并报错 - 若需大量只读逻辑，应拆分为“事务外预读 + 事务内确定性操作”，比如先查 ID 列表，再在事务中批量更新对应文档
- 对延迟不敏感的报表类读取，应彻底移出事务 —— 事务越短越好，避免阻塞主节点写入
- 使用
session.withTransaction()时，回调函数内部所有数据库操作共享同一会话，无需也不应手动设置readPreference
驱动版本与兼容性注意点
较老的 Node.js 驱动（如 3.x）在事务中忽略 readPreference 设置，但行为不一致；4.0+ 驱动严格遵循 Server 规则，遇到非法偏好立即 throw。Python PyMongo、Java Driver 同样适用该限制。
- Driver 4.13+ 在构造
ClientSession时支持传入defaultTransactionOptions，但其中不包含readPreference字段 —— 它被硬编码为primary - 连接字符串中指定
readPreference=primaryPreferred不影响事务，事务内仍强制primary；但非事务操作会受其影响 - 使用
mongosh测试时，session.startTransaction({ readConcern: { level: 'snapshot' } })是合法的，但加readPreference字段会直接语法报错
事务不是万能的读写封装，它的代价是强一致性约束和节点绑定。把读操作塞进事务前，先确认它是否真需要和写操作共享同一份快照 —— 大多数时候，答案是否定的。
