readConcern="linearizable"在聚合中生效需同时满足三条件：路由至主节点、写操作已majority落盘、集群启用writeConcernMajorityJournalDefault:true；否则仍读旧数据。
readConcern: "linearizable" 在聚合操作中不生效，除非满足全部硬性前提——多数人配置完发现没用，是因为漏掉了其中一环。
为什么聚合操作加了 readConcern="linearizable" 还是读到旧数据
根本原因不是驱动或语法错，而是 MongoDB 对 linearizable 的实现有严格依赖链：它要求操作必须路由到主节点 + 写操作已用 w: "majority" 确认 + 集群开启 writeConcernMajorityJournalDefault: true。聚合本身不触发写，所以它“线性一致”的前提是：它所读的文档，其最后一次修改必须已通过 majority 写入并落盘。
常见错误现象：
- 聚合返回结果和刚执行的
updateOne不一致，即使该 update 明确设了write_concern={"w": "majority", "j": True} - 连接串里写了
&readConcernLevel=linearizable，但驱动报错Command not supported with linearizable read concern - 在
mongosh里手动执行db.collection.aggregate(..., {readConcern: {level: "linearizable"}})成功，但 PyMongo 报错
关键点：只有针对单个集合的聚合（不含 $lookup 跨库、不含分片路由）且显式指定 read_preference=ReadPreference.PRIMARY 时，linearizable 才可能起效。
PyMongo 中正确启用 linearizable 聚合的三步实操
必须同时满足以下三点，缺一不可：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 客户端连接时强制读主：
read_preference=ReadPreference.PRIMARY（不能用字符串"primary"，否则报TypeError） - 聚合操作级显式传
read_concern=ReadConcern("linearizable")（注意不是字符串，也不是字典） - 对应集合的写操作必须长期使用
write_concern={"w": "majority", "j": True}，且副本集配置中writeConcernMajorityJournalDefault为true（可通过rs.conf().settings.writeConcernMajorityJournalDefault验证）
示例代码：
from pymongo import MongoClient, ReadPreference, ReadConcern
client = MongoClient(
"mongodb://rs1:27017,rs2:27017,rs3:27017/?replicaSet=myRs",
read_preference=ReadPreference.PRIMARY
)
db = client.mydb
coll = db.mycoll
<h1>正确：聚合时显式带 read_concern</h1><p>result = list(coll.aggregate(
[{"$match": {"status": "active"}}],
read_concern=ReadConcern("linearizable")
))
容易被忽略的兼容性陷阱
linearizable 不是开关，它是个高代价一致性模型，副作用明显：
- 仅支持 WiredTiger 引擎；MMAPv1 下直接拒绝请求
- 只对
PRIMARY节点有效，若主节点临时不可用（如选举中），聚合会直接失败，不会降级 - 性能开销大：每次请求都要触发一次 majority commit point 检查，延迟比
majority高 2–5 倍 - 不支持事务内嵌套聚合；事务中只能用
read_concern="snapshot"或"majority" - Python 驱动必须 ≥ 4.3（对应 MongoDB Server ≥ 5.0），低版本会静默忽略或报
InvalidName
如果你只是想避免脏读，read_concern="majority" + read_preference=ReadPreference.PRIMARY 组合通常更稳、更快、兼容性更好。
验证 linearizable 是否真正在工作
别只看代码有没有报错——要验证行为：
- 停掉一个从节点，让副本集只剩 2 个健康节点（3 节点集群中），此时
w: "majority"实际等价于w: 2；如果聚合仍能返回最新数据，说明linearizable生效 - 在主节点上执行
db.adminCommand({setFeatureCompatibilityVersion: "5.0"})后，再运行db.runCommand({getCmdLineOpts: 1})确认storage.journal.enabled: true - 用
mongostat --host rs1:27017观察netIn和conn，对比开启前后延迟毛刺是否增多
真正难的不是配参数，而是判断“此刻是否需要线性一致”——95% 的聚合场景其实只需要 majority 级别读关注就够了。强行上 linearizable 只会让故障恢复变慢、运维排查更复杂。
