MongoDB 5.0副本集tags仅为readPref()手动路由的元数据标记，非自动业务路由开关；生效需客户端显式指定匹配全部key-value的tag读偏好，且目标节点须在线、为SECONDARY状态。
直接结论： MongoDB 5.0 副本集的 tags 不是“业务专属标签”的自动路由开关，它只是配合 readPref() 手动指定读节点的元数据标记；真正生效的前提是客户端显式调用带 tag 过滤的读偏好，且目标节点必须同时满足：在线、可读（secondary 状态）、匹配全部 key-value 对。
为什么 rs.conf() 里配了 tags 却查不到预期节点？
常见错误现象是执行 db.collection.find({}).readPref("secondary", [{"dc":"east"}]) 后仍从 primary 或其他 secondary 返回结果。这不是 bug，而是 MongoDB 的 fallback 行为：当找不到完全匹配的 secondary 节点时，会退回到 primary 读取（前提是 read preference 允许，比如 secondaryPreferred）。
- 确认节点状态：用
rs.status()检查目标节点是否为"stateStr" : "SECONDARY"，且"health" : 1 - 确认 tags 完全匹配：
conf.members[1].tags = {"dc":"east","env":"prod"}，那么查询时必须传[{"dc":"east","env":"prod"}]，少一个或值错就匹配失败 - 注意大小写和空格：
"DC":"EAST"和"dc":"east"是不同 tag - 副本集配置未生效：修改后必须调用
rs.reconfig(conf)，且新配置 version 递增；旧配置可能还在缓存中
如何安全地给 secondary 节点添加业务 tags？
操作本身简单，但容易因并发 reconfig 或版本冲突失败。MongoDB 5.0+ 要求每次 rs.reconfig() 必须基于当前最新配置（rs.conf()），不能复用旧变量。
- 先获取实时配置：
conf = rs.conf()（不是缓存变量） - 定位目标 member：用
conf.members.findIndex(m => m.host === "node2:27017")比硬写[1]更可靠 - 设置 tags 字段：
conf.members[i].tags = {"biz":"payment","region":"cn-north"}；若原无tags字段，需完整赋值，不能只改子字段 - 强制更新 version：
conf.version++（否则rs.reconfig()拒绝执行） - 执行重配：
rs.reconfig(conf, {force: true})——force在 primary 不可用时必要，但生产环境慎用
客户端读请求怎么真正用上这些 tags？
服务端配好 tags 只是第一步，客户端驱动（如 PyMongo、Node.js Driver）必须显式构造带 tag 的 readPreference，且注意语法差异。
- mongosh 中：
db.collection.find().readPref("secondary", [{"biz":"payment"}])—— 第二个参数是数组，每个元素是完整 tag 文档 - PyMongo 中：
collection.find({}, read_preference=ReadPreference.SECONDARY, tag_sets=[{"biz":"payment"}]) - Node.js Driver：
collection.find({}, { readPreference: { mode: "secondary", tags: [{ biz: "payment" }] } }) - 不支持模糊匹配：无法用
{"biz": /pay.*/}或通配符；[{"biz":"payment"}, {"biz":"user"}]表示“优先找 payment，找不到再找 user”，不是 OR 关系
最容易被忽略的一点：tag 路由只影响读，不影响写；所有写操作永远发往 primary，无论你配了多少个 tag。如果业务真需要“写到特定机房”，得靠分片集群 + zone sharding，副本集的 tags 仅用于读分离场景。
