nearest模式并非按地理距离“就近”，而是基于客户端到各节点的平均ping时间（RTT）和localThresholdMS阈值筛选符合条件的节点，再随机选取；若secondary因同步延迟、网络抖动、标签或maxStalenessSeconds限制被剔出eligible列表，则只剩primary可选。
nearest 模式真能“就近”吗？先看它怎么选节点
nearest 不是按地理距离或 IP 段判断“近”，而是基于客户端到每个副本集成员的平均 ping 时间（RTT）动态计算。驱动会向所有 eligible 成员发心跳探测，取多次 ping 的平均值，再用 localThresholdMS（默认 15ms）划出一个延迟窗口：只保留 RTT ≤ 最快节点 RTT + localThresholdMS 的成员，然后从中随机挑一个——这个“随机”不轮询、不负载均衡，只是选一个可用节点发请求。
常见误判：看到连接串写了 readPreference=nearest 就以为流量自动分摊了，结果监控里全是 primary 在扛读——大概率是 secondary 节点因网络抖动、CPU 高或同步延迟被踢出 eligible 列表，只剩 primary 符合窗口条件。
- 必须确认 secondary 节点状态是
SECONDARY，不是RECOVERING或STARTUP2 - 检查
rs.status().members[n].pingMs是否稳定且未超阈值（比如 >100ms） - 如果 secondary 有
hidden: true或priority: 0，它不会进入候选池，nearest直接无视它
连接字符串里写 nearest，为什么还是读到了 Primary？
因为 nearest 的 eligible 成员列表受三重过滤：节点状态、标签匹配、maxStalenessSeconds。哪怕你没显式设 maxStalenessSeconds，驱动也会用默认值（PyMongo 是 90 秒，Node.js Driver 是 60 秒），只要 secondary 的 optimeDate 落后 primary 超过该值，它就被自动剔除。
典型现象：跨机房部署时，A 地区应用连 B 地区的 secondary，同步延迟常达 2–5 秒；但若 maxStalenessSeconds=30，这个 secondary 就永远进不了 nearest 的候选池。
- 查同步差距：
rs.printSlaveReplicationInfo()看syncedTo时间戳差 - 放宽限制（谨慎）：连接串加
&maxStalenessSeconds=120，但要接受更高数据延迟 - 标签强制路由更可靠：比如给 A 地区 secondary 打标签
{"region": "east"}，连接时用&readPreference=nearest&readPreferenceTags=region:east
GridFS 场景下 nearest 完全失效？原因和绕过方式
GridFS 的两阶段读取（先查 fs.files 元数据，再拉 fs.chunks 数据块）导致 readPreference=nearest 只作用于第一阶段。第二阶段 openDownloadStream() 默认走 primary，因为官方驱动发现 secondary 上缺失 {files_id: 1, n: 1} 索引后，会静默降级——这不是 bug，是保护性 fallback。
强行让 chunk 也走 nearest，得拆开流程手动控制：
- 所有 secondary 必须提前建索引：
db.fs.chunks.createIndex({ files_id: 1, n: 1 }, { readPreference: "primary" }) - 元数据查询用
bucket.find(..., { readPreference: "nearest" }) - chunk 读取不用
openDownloadStream()，改用原生 collection 查询：db.fs.chunks.find({ files_id: xxx, n: { $gte: a, $lte: b } }, { readPreference: "nearest" }) - 连接串中补上
&localThresholdMS=30，避免因微小 RTT 差异把 nearby secondary 排除
事务内用 nearest 会直接报错
任何带 startTransaction() 的操作，无论连接串或游标怎么设 readPreference，驱动都会强制覆盖为 primary。这是 MongoDB 协议层硬性限制，不是配置问题。
如果你的应用在事务里混用了读操作（比如先查再改），又指望 nearest 分流，结果只会收到 CommandNotSupportedOnSecondary 错误。
- 事务内所有读必须走 primary，别试图绕过
- 非事务读（如报表、历史查询）才适合
nearest，且需确保这些操作不意外卷入事务上下文 - Node.js 中注意
session.withTransaction()的闭包范围，避免外部查询被隐式绑定
readPreference=nearest，而是 secondary 节点是否在 eligible 列表里站稳了——这取决于它的同步进度、网络稳定性、索引完备性，以及你有没有在驱动层主动放宽那些默认却严苛的过滤条件。 
