writeconcern需按场景分层配置：客户端级设默认值但可被覆盖，集合级最常用且优先级居中，事务内须统一指定；w=0有丢数据风险，务必验证集群实际投票节点数。
WriteConcern 不是“设一次就完事”的配置，它必须按使用场景选层级、按一致性要求选参数，否则容易出现写入成功但数据不可读、或写入卡死超时等问题。
客户端级别设置 WriteConcern（全局默认）
适用于大多数操作都需强一致性的服务，比如支付类写入。但要注意：它会被更细粒度的设置覆盖（如集合级、事务级），所以不是“最高优先级”。
Go 驱动中常用方式：
client, _ := mongo.Connect(ctx, options.Client().ApplyURI("mongodb://rs1:27017,rs2:27017,rs3:27017").SetWriteConcern(writeconcern.Majority()))
Node.js 驱动可通过 URI 设置：
mongodb://rs1:27017/?w=majority&j=true&wtimeout=5000
-
w=majority表示写入必须被多数投票节点确认，适合防止主节点宕机后丢失已确认写入 -
j=true强制日志落盘，避免断电丢数据；但会显著降低吞吐量 -
wtimeout=5000是硬性保护，防止因节点故障导致写入无限等待
集合级别覆盖 WriteConcern（最常用）
日志、监控等弱一致性场景常需降级写关注，而用户订单等关键数据需升级，这时集合级设置最实用——它比客户端级优先，又比单次操作传参更轻量。
Go 示例：
collection := client.Database("mydb").Collection("orders").WithOptions(options.Collection().SetWriteConcern(writeconcern.W2()))
Node.js 示例：
const ordersColl = db.collection('orders', { writeConcern: { w: 2, j: true } });
-
w=2要求主节点 + 1 个从节点确认，比w=majority更快（尤其在 5 节点集群中，majority=3，而 w=2 永远只需 2 个） - 注意：
w=2在只有 2 个数据节点的副本集中等价于w=majority，但在 3+ 节点时行为不同，务必核对实际成员数 - 隐藏节点、延迟节点若
votes > 0，也会参与w=majority计算，可能意外拉高确认门槛
事务内不能单独设 WriteConcern
这是最容易踩的坑：事务中所有写操作共享同一 WriteConcern，且只能在 startTransaction() 时通过 TransactionOptions 统一指定，不能对 insert 或 update 单独调用 WithWriteConcern()。
- Go 中必须这样写：
session.StartTransaction(options.Transaction().SetWriteConcern(writeconcern.Majority()))
- 如果事务里混用高一致性（如用户余额）和低一致性（如操作日志）写入，得拆成两个事务，或改用单文档原子操作（如
$inc）替代 - 事务默认继承客户端级
WriteConcern，但一旦显式设置，就完全覆盖——哪怕你只设了w=1，整个事务也按此执行
w=0 和 Unacknowledged 的真实风险
很多人以为 w=0 只是“更快”，其实它连主节点内存写入成功都不保证：网络中断、主节点崩溃、甚至驱动进程 crash 都可能导致“看似成功实则丢数据”。
- 它不等于“fire-and-forget”，而是“send-and-hope”——驱动根本不等任何响应，连连接异常都捕获不到
- 仅适合埋点、审计日志等允许丢失的场景；绝不能用于状态变更、计数器更新等业务逻辑
- Go 驱动中
writeconcern.Unacknowledged()和writeconcern.W0()等价，但后者更直白，建议统一用W0()
hidden 还留着 votes: 1，这时候 w=majority 可能突然卡住。上线前务必用 rs.status() 确认实际投票节点数，并在压测中观察 wtimeout 是否频繁触发。
