刚写入就查不到，主因是writeconcern未设对或未生效：w:0不等确认、w:1仅主节点内存写入，均不保证从节点同步；需匹配readpreference="primary"或搭配readconcern="majority"且写操作启用w:"majority"+j:true。
刚写入就查不到，八成是 writeConcern 没设对，或者压根没生效——不是代码漏了，就是默认值在副本集里不够用。
writeConcern 为 0 或未显式设置时，写入可能“假成功”
Node.js 驱动（如 mongodb 5.x+）默认 w: 1，但如果你用的是老版本驱动、或手动传了 { writeConcern: { w: 0 } }，那 insertOne 调用会立刻返回，连主节点内存都还没写完，更别说同步到从节点。此时立刻 find，自然查不到。
-
w: 0：不等任何确认，网络发出去就返回；err只能捕获连接错误，写失败静默丢弃 -
w: 1（默认）：只等主节点写入内存 oplog，不等 journal 刷盘，主节点宕机即丢失 - 副本集部署下，
w: 1不保证从节点有数据，读请求若打到从节点（比如readPreference: "secondary"），大概率查不到
副本集里查不到，重点检查 readPreference 和 writeConcern 匹配性
写进去了却读不出来，常见于读写分离配置失配：写到了主节点，但查询路由到了尚未同步的从节点。这时单靠提高 writeConcern 不够，得配合 readPreference 或 readConcern。
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 如果必须立刻读到刚写的数据，
readPreference应设为"primary"（默认），避免读从节点 - 若要用从节点分担读压力，且要求强一致性，需同时设
readConcern: { level: "majority" }——但前提是写操作也用了w: "majority"，否则读不到“已确认不回滚”的数据 -
readPreference: "primaryPreferred"在主节点不可用时降级读从节点，但此时无法保证刚写入的数据可见
事务中 writeConcern 必须在 commitTransaction 时指定
很多人在事务里给 insertOne 单独加 writeConcern，结果无效还报错：Cannot specify write concern in both transaction options and operation。事务内所有写操作强制走 w: 1，只有 commitTransaction 这一步才真正应用 writeConcern。
- ✅ 正确写法：
session.commitTransaction({ writeConcern: { w: "majority", j: true, wtimeout: 5000 } }) - ❌ 错误写法：
collection.insertOne(doc, { writeConcern: { w: "majority" } }, { session }) - 若副本集健康节点数不足（比如只有 2 个投票节点），
w: "majority"实际算出来是 2，但其中 1 个临时失联，就会卡满wtimeout后抛WriteConcernFailed
生产环境别依赖全局默认，显式传参更可控
MongoDB 副本集默认全局 writeConcern 是 { w: "majority" }，听起来很安全，但有两个坑：一是没配 wtimeout，网络抖动时请求无限阻塞；二是 "majority" 不等于落盘，没加 j: true 仍可能丢数据。
- 显式设置比依赖默认更可靠，尤其在多环境（dev/staging/prod）配置不一致时
-
wtimeout必须设，推荐5000（5 秒），太短容易误超时，太长拖垮连接池 - 单机开发时
w: "majority"会卡住（因为多数 = 1，但单节点无复制，实际行为异常），应切回w: 1
最常被忽略的一点：writeConcern 生效的前提是驱动真正在用它——检查你调用的是否是带 callback 或 await 的写方法（如 insertOne()），而不是漏掉 await 导致查询发起时写操作还在 event loop 里排队。
