MongoDB WriteConcern 配置：别让“写入成功”变成虚假确认
当谈到 MongoDB 的 WriteConcern（写入关注）时，许多开发者的第一反应是“设置为 majority 就万事大吉”。然而，实际情况远比想象复杂——WriteConcern 并非一次性配置就能永久生效，它必须根据具体业务场景选择合适的层级，并依据一致性需求调整参数，否则极易出现“写入成功但数据无法读取”或“写入操作超时卡死”等棘手问题。
首先了解一个核心原则：WriteConcern 必须在三个层级中做出选择——客户端级、集合级、事务级。每个层级具有不同的优先级和适用场景，混用不当很容易引发问题。
客户端级别 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 覆盖（最常用设置）
在实际项目中，经常会遇到这样的需求：对于日志、监控等弱一致性数据，需要降低 WriteConcern 级别；而对于订单等关键业务数据，则需要提升写入确认强度。此时，集合级别的 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 个从节点共 2 个确认，比w=majority速度更快。例如在 5 节点集群中，majority 需要 3 个确认，而 w=2 始终只需 2 个确认- 但
w=2在只有 2 个数据节点的副本集中等价于w=majority，而在 3+ 节点时行为不同——务必核对实际成员数 - 隐藏节点、延迟节点如果
votes > 0，也会参与w=majority计算，可能意外拉高确认门槛
事务内无法单独设置 WriteConcern
这是最容易踩坑的地方，没有之一。事务中的所有写操作共享同一个 WriteConcern，并且只能在启动事务时通过 TransactionOptions 统一指定，无法对单个 insert 或 update 操作单独调用 WithWriteConcern()。
- Go 代码必须如下所示：
session.StartTransaction(options.Transaction().SetWriteConcern(writeconcern.Majority()))
- 如果事务中同时包含高一致性要求（如用户余额更新）和低一致性要求（如操作日志记录），则需要拆分为两个独立事务，或者改用单文档原子操作（如
$inc）来实现 - 事务默认继承客户端级别的 WriteConcern，但一旦在事务选项中显式设置，则会完全覆盖客户端级配置——即使只设置了
w=1，整个事务都将按照该值执行
w=0 与 Unacknowledged 的实际风险
许多人误以为 w=0 仅仅是“更快”，但实际上它连主节点内存写入的成功与否都无法保证：网络中断、主节点崩溃、甚至驱动进程崩溃都可能导致“看似成功、实则数据丢失”的情况。
- 它并不等同于“fire-and-forget”（发后即忘），而是“send-and-hope”（发送并祈祷）——驱动程序根本不等待任何响应，甚至连连接异常都无法捕获
- 仅适用于埋点、审计日志等可容忍丢失的场景；绝不能用于状态变更、计数器更新等关键业务逻辑
- 在 Go 驱动中，
writeconcern.Unacknowledged()与writeconcern.W0()等价，但后者更直观，建议统一使用W0()
真正棘手的并非如何设置，而是设置之后未进行验证。例如，副本集成员的投票数发生变化，或者某个从节点被标记为 hidden 却仍保留 votes: 1，此时 w=majority 可能突然导致写入卡住。上线前务必使用 rs.status() 确认实际投票节点数量，并在压力测试中观察 wtimeout 是否频繁触发。不要等到线上出现问题才想起检查——那时已经为时已晚。
