MongoDB副本集默认w:1无法保证数据不丢失，生产环境必须显式设w:"majority"并配wtimeout（如5000），通过驱动层统一配置；wtimeout仅对w>1生效，w:1下无效；majority动态适配节点数，w=N为固定值；majority+j:true确保落盘且多数确认。
WriteConcern 是 w: 1，即只要主节点（primary）确认写入就返回成功——这在多数故障场景下**无法保证数据不丢失**。生产环境必须显式调整，不能依赖默认。
全局默认 WriteConcern 应该在客户端级别统一设置
逐个操作加 writeConcern 容易漏，尤其 ORM、bulkWrite、聚合管道中的子写入根本不会继承你手动传的参数。驱动层或应用代码里用 withWriteConcern() 或初始化 MongoClient 时设 WriteConcern 才可靠。
- Go 驱动：用
options.Client().SetWriteConcern(writeconcern.Majority()) - .NET 驱动：在
MongoClientSettings上赋值WriteConcern = WriteConcern.WMajority - Node.js 驱动：连接 URI 中加
&w=majority&wtimeout=5000，或构造MongoClient时传writeConcern: { w: "majority", wtimeout: 5000 } - Java Reactive Streams 驱动：用
MongoClientSettings.builder().writeConcern(WriteConcern.MAJORITY)
w: "majority" 表示写入需被大多数有投票权的数据节点确认（含 primary），不是“多数副本集成员”——比如 5 节点中 2 个是 arbiter，实际数据节点只有 3 个，“majority” 就是 2。
wtimeout 必须显式配，且只对 w > 1 生效
wtimeout 单位是毫秒，超时后 MongoDB 不会回滚已写成功的节点，只抛出 WriteConcernFailed 错误，业务必须自己判断是否重试。
-
wtimeout: 0等同于未设置，可能无限等待（如一个 secondary 持久离线） -
w: 1下设wtimeout无效，因为主节点响应极快，超时机制不触发 - 生产建议从
wtimeout: 5000起步，覆盖常见网络抖动；高一致性要求可压到 2000，但要监控超时率
配置文件 setParameter 方式不推荐用于生产
/etc/mongod.conf 中通过 setParameter.writeConcern 设置，看起来一劳永逸，但有硬伤：
- 只影响 mongod 进程启动后新建立的连接，已有连接不受影响
- 无法区分数据库或集合粒度，所有操作强制套同一策略，灵活性归零
- 升级或重启后若配置遗漏，容易回退到
w: 1，而监控难发现 - 部分云厂商托管实例（如阿里云 MongoDB）不支持该参数
它适合测试环境快速验证，但线上应由驱动层控制，和业务逻辑耦合更可控。
majority 和 w=N 的行为差异常被误解
这两个选项看似都能提升可靠性，但语义和适用场景不同：
-
w: "majority"动态计算，节点增减时自动适配；适用于节点数可能变化的集群（如弹性扩缩容） -
w: 3是固定数字，当副本集只有 3 个数据节点时等价于 majority；但若扩到 5 节点，w: 3就比 majority（需 3）弱（因 majority 变成需 3），而w: 5又可能因某个节点临时不可用导致写失败 -
w: "majority"+j: true（即writeconcern.Majority().Journaled()）才能确保写入已落盘且跨多数节点，这是强持久性组合
真正容易被忽略的是：即使设了 majority，如果副本集当前可用投票节点数不足 majority（比如 3 节点集群挂掉 1 个，只剩 2 个），写操作会直接失败——这不是 bug，是设计使然。这时得靠运维快速恢复节点，或降级为 w: 1（需业务接受风险）。
