mongodb副本集的写关注（write concern）需在客户端、数据库或集合级别显式设置，否则继承默认值（通常为"majority"），但该默认值可能被集群配置覆盖；c#和java驱动必须在代码中指定，如writeconcern.wmajority或writeconcern.builder().w(2).j(true).wtimeout(1000)，连接字符串参数仅作用于客户端级默认且无法覆盖集合级设置。
MongoDB副本集的写关注（write concern）不是“设一次就全局生效”的配置，而是按调用层级动态生效的——你必须在客户端、数据库或集合级别显式设置，否则会继承默认值（通常是 "majority"），但这个默认值本身可能被集群配置覆盖。
如何在驱动程序中设置 write concern（以 C# 和 Java 为例）
驱动程序里不能靠改配置文件或 mongosh 命令来影响应用代码的行为，必须在代码中明确指定。
-
WriteConcern.WMajority是最常用的安全选择：要求多数有投票权节点（包括主节点）将操作写入 oplog 后才返回确认 -
WriteConcern.W2在 3 节点副本集中等价于WMajority，但在 5 节点时只写到 2 个节点，不保证多数，慎用 - Java 驱动中用
WriteConcern.builder().w(2).j(true).wtimeout(1000)构造更细粒度控制；C# 中推荐用WriteConcern.Acknowledged.With(w: 2, j: true, wtimeout: 1000) - 如果用连接字符串传参（如
?w=2&j=true&wtimeout=1000），它只作用于客户端级默认，无法覆盖 collection 级设置
为什么 rs.reconfig() 里的 getLastErrorDefaults 不起作用？
这是最容易误解的一点：settings.getLastErrorDefaults 只对旧版驱动（v3.x 及之前）的 getLastError 命令有效，而现代驱动（v4+）完全绕过该命令，直接使用 writeConcern 字段。所以即使你在副本集配置里写了：
{ "settings": { "getLastErrorDefaults": { "w": "majority", "j": true } } }
对 C#、Java、Node.js 等新驱动也完全无效。它只影响 mongosh 里手动调用 db.runCommand({ getLastError: 1 }) 这类遗留用法。
mongosh 中临时设置 write concern 的真实效果
db.getMongo().setWriteConcern({ w: 2, wtimeout: 500 }) 只影响当前 mongosh 会话后续的 insertOne()、updateOne() 等 shell 命令，不改变任何驱动行为，也不持久化。它本质是给 shell 自己发命令时加了个默认参数。
- 执行后所有 shell 写操作自动带上
{ w: 2, wtimeout: 500 }，但db.collection.insert(..., { writeConcern: { w: 1 } })仍会覆盖它 - 重启 mongosh 就失效；对其他客户端零影响
- 注意：
wtimeout单位是毫秒，且仅当w > 1时才生效——w: 1下设wtimeout会被忽略
自定义标签写关注（tag-aware write concern）要避开的坑
用标签做写关注的前提是副本集成员已打标，且 settings.getLastErrorModes 正确声明了标签规则。但实际踩坑最多的是：
- 标签名大小写敏感：
"dc": "east"和"DC": "east"是两个不同标签 - 延迟节点（
secondaryDelaySecs > 0）即使打了标签，也无法参与"majority"计算，除非你显式用w: { tag: "xxx" } -
getLastErrorModes必须在rs.reconfig()中整体提交，不能单独 patch；且修改后需所有节点重载配置（通常要重启或强制 reconfig） - 标签写关注只在副本集生效，分片集群中
mongos会忽略标签，只按分片内副本集规则处理
真正决定写操作是否“落盘可靠”的，从来不是某处静态配置，而是每次写请求携带的 writeConcern 对象本身。别指望靠一次 reconfig 或一个连接字符串参数一劳永逸——它必须出现在你发出去的每个写命令上下文中。
