聚合操作必须在命令级显式指定readPreference，不能依赖连接级全局设置；$lookup等阶段要求同节点读取以保证一致性；分片集群中由mongos控制读偏好。
聚合操作必须显式指定 readPreference，不能依赖全局设置
mongosh 或驱动中对连接对象调用 Mongo.setReadPref() 不会影响 aggregate() 命令的路由行为——这是最常见的误判点。MongoDB 5.0+ 的聚合操作（尤其是含 $lookup、$facet 等阶段时）会忽略连接级读偏好，除非你在聚合调用本身中明确传入 readPreference 选项。
原因在于：聚合可能被拆分到多个节点执行（如分片集群中的 mongos 合并阶段），或涉及跨集合/跨数据库引用，此时服务器选择逻辑优先级高于客户端全局偏好。
- 在 mongosh 中，必须写成：
db.collection.aggregate(pipeline, { readPreference: "secondary" }) - Java 驱动需用
AggregateIterable.readPreference(ReadPreference.secondary()) - Node.js 驱动同理：
collection.aggregate(pipeline).readPreference("secondary") - URI 中的
readPreference=secondary对聚合无效，仅影响普通 find/update/delete
readPreference=nearest 在聚合中可能返回不一致结果
当聚合管道包含写操作（如 $out、$merge）或需要因果一致性的阶段时，nearest 模式会导致节点选择与写入节点不匹配，进而触发重试或报错 Cannot use read preference nearest with write concern。
更隐蔽的问题是：即使纯读聚合，若使用 nearest 且副本集存在网络分区（例如某从节点延迟突增但未被剔除），聚合中间结果可能来自不同 staleness 程度的节点，最终合并后出现逻辑矛盾（比如时间窗口内状态倒置）。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 安全做法：聚合只用
primary（强一致）、secondaryPreferred（读写分离兜底）或明确标签限定的secondary - 禁用
maxStalenessSeconds与nearest组合——MongoDB 5.0 不支持该组合用于聚合 - 验证是否生效：在 mongosh 中执行
db.runCommand({ aggregate: "coll", pipeline: [], explain: true })，检查返回中executionStats.executionStages.shards.*.host是否符合预期节点
带 $lookup 的聚合必须走 primary 或同机房 secondary
如果 $lookup 引用的是同一副本集内的另一个集合（非分片），MongoDB 5.0 要求所有参与集合的读取必须发生在同一个节点上，否则报错 Unable to execute query against any replica set member 或静默返回空结果。
这是因为 $lookup 需要保证源集合和被查集合的快照一致性，而跨节点读取无法满足该前提——即使两个 secondary 节点都标称“最新”，它们的实际 oplog 应用进度必然有毫秒级偏差。
- 正确配置示例（mongosh）：
db.orders.aggregate([ { $lookup: { from: "customers", localField: "cid", foreignField: "_id", as: "cust" } } ], { readPreference: { mode: "secondary", tags: [ { "region": "cn-east" } ] } }) - 错误配置：
readPreference: "nearest"—— 可能选中不同 region 的节点，导致 lookup 失败 - 绕过方案：改用应用层两次查询（先查 orders，再按 cid 批量查 customers），但失去原子性
分片集群中聚合的读偏好实际由 mongos 控制
在分片集群里，你给集合设置的 readPreference 会被 mongos 忽略；真正起作用的是 mongos 连接字符串里的 readPreference 参数，或客户端连接 mongos 时指定的偏好。
这是因为 mongos 是聚合的协调者：它先将 pipeline 拆分下发到各分片，再合并结果。各分片内部的读节点选择，完全由 mongos 的偏好决定，而非下游 mongod 实例的本地设置。
- 验证方式：连接
mongos后运行db.runCommand({ getCmdLineOpts: 1 })，确认输出中parsed.net.readPreference存在且值正确 - 生产建议：分片集群统一用
readPreference=secondaryPreferred，避免mongos单点故障时整个聚合不可用 - 注意：分片集群不支持对单个聚合操作单独覆盖
readPreference，必须在连接层或mongos配置中设定
mongos 级的优先级完全不同，且 5.0 对 $lookup 和分片场景做了硬性约束。漏掉任意一层，都可能让路由失效或引发静默数据异常。 
