ReadPreference 设为 primary 并非禁止从节点读取，而是客户端主动只向主节点发送读请求；从节点仍正常同步与服务，只是驱动未选择它。
ReadPreference 设为 primary 确实能避免读到过期数据，但不是“防止从节点读取”的配置动作
很多人误以为把 ReadPreference 设成 primary 是在“限制从节点不被读”，其实它只是让客户端**主动只发请求给主节点**。从节点本身完全不受影响，照常同步、照常提供服务——只是你的驱动没选它而已。真正“防止从节点读取过期数据”的前提是：你根本没让它参与读请求。
常见错误现象：
– 明明代码里写了 ReadPreference.primary()，却还是偶尔读到旧值
– 使用了多线程/连接池，部分请求意外落到 secondary
– 驱动版本老（如 pymongo ReadPreference 默认是 primaryPreferred，写死不生效
- 确认驱动实际生效的读偏好：打印
collection.read_preference或抓包看 wire protocol 中的readPreference字段 - pymongo 示例中，必须显式传入参数，比如：
collection.find({}, read_preference=ReadPreference.PRIMARY)；仅在 client 初始化时设read_preference不会覆盖 collection 级别设置 - Node.js 的
mongodb驱动中，readPreference: 'primary'要放在每个操作的options里，或通过db.collection(..., { readPreference: 'primary' })构建新 collection 实例
为什么 primary 是唯一能保证强一致读的选项
MongoDB 副本集默认不提供跨节点的线性一致性（linearizability）。只有主节点能保证你读到的是已提交、未回滚、且最新写入的结果。secondary 的 oplog 同步有延迟，哪怕只差几毫秒，也可能返回上一个版本的文档。
-
primaryPreferred在主挂了时自动切 secondary，此时无法保证数据新鲜度——这不是 bug，是设计行为 -
nearest可能路由到延迟最大的节点，尤其跨机房部署时，延迟可达秒级 - 即使开启
writeConcern: { w: "majority" }，也只约束写入传播范围，不改变 secondary 的读视角；读操作永远看不到 majority 写入的“即时效果”，除非你强制读主
配置后仍读到旧数据？检查这三处隐性绕过点
设了 ReadPreference.PRIMARY 还出问题，大概率是被其他机制悄悄覆盖了。
- 事务内默认忽略
ReadPreference：MongoDB 4.0+ 的多文档事务中，所有读自动绑定到开启事务的 primary，但如果你在事务外另起一个 session 并复用旧 collection 实例，可能误读 secondary - 聚合管道里的
$lookup或分片集群的$unionWith可能触发隐式 secondary 读（取决于 pipeline 执行位置和驱动实现） - 监控工具或 ORM 自动注入读偏好：比如 Mongoose 的
Model.read('p')会被覆盖，或某些 APM 插件强制改写查询选项
生产环境别只靠 ReadPreference 做一致性兜底
它解决的是“读哪个节点”，不是“读什么时间点的数据”。如果业务真需要严格因果序（比如用户刚提交订单，立刻查列表要看到），光靠 primary 不够——主节点自己也有 write concern 和 journal commit 的微小窗口。更稳的做法是结合 afterClusterTime（4.0+ 支持）或应用层加 version 字段校验。
最容易被忽略的一点：副本集成员状态变化（比如主切换）会导致连接重置，而某些旧版驱动在 reconnect 后不会自动恢复原来的 ReadPreference，得手动重建 collection 实例。
