深入理解MongoDB的findAndModify：原子操作与并发控制
findAndModify 为什么不是“绝对原子”
先说一个核心判断：findAndModify 在单文档级别确实是原子的，但这并不意味着整个操作对外界是完全隔离的“金钟罩”。它的本质，是把“查找、更新（或删除）、返回旧/新文档”这三步，打包成一个存储引擎层面的原子动作——注意，这个原子性的粒度，仅限于该文档的写锁。
一旦你的操作里用上了 sort 排序或者 projection 投影来筛选文档，情况就微妙了。实际执行时，引擎可能先扫描一批文档，找到目标后再加锁修改。这个“扫描”到“加锁”之间，存在一个极其微小的时间窗口。就在这个窗口里，其他并发的写操作完全有可能插进来，从而影响你最终结果的一致性。
- 任务队列场景：如果你想用它实现“取出一个未被占用的任务”，必须将查询和更新写在一起。例如：
query: { status: "pending" }配合update: { $set: { status: "processing", workerId: "w123" } }。如果只查不改，那就毫无并发保护可言。 - upsert的坑：不加
upsert: true时，如果没匹配到文档，它只是安静地返回null。但如果加了upsert: true却没设置update字段，它会直接插入一个空文档——这是新手常踩的雷区。 - 分片集群限制：在分片环境中，
findAndModify要求查询条件必须包含完整的分片键，否则会直接报错Command findAndModify requires shard key，这一点没有商量余地。
替代方案：replaceOne + 条件更新更可控
当业务逻辑稍微复杂一点，比如需要先校验某个字段的值再决定如何更新时，findAndModify 那单次表达的能力很快就见顶了。这时候，转向 replaceOne 或者配合 $set/$inc 等操作符的 updateOne，思路反而更清晰，也更容易测试和调试。
- 返回结构更直白：
updateOne返回的是{ matchedCount, modifiedCount, upsertedId }，这种结构一目了然，比findAndModify那种混合了文档内容和操作状态的返回体要友好得多。 - 实现CAS语义：如果想实现“只在版本号为5时更新”这类乐观锁控制，直接用
filter: { _id: id, version: 5 }作为条件即可，没必要绕进findAndModify那套嵌套的query和update逻辑里。 - 注意驱动差异：不同语言驱动的版本差异是个实际问题。比如
pymongo从4.x开始就弃用了find_and_modify方法，只保留find_one_and_update；Node.js 的mongodb包里对应的是findOneAndUpdate。名字变了，核心语义没变，但参数顺序和某些默认行为可能有细微差别，迁移时需要留意。
并发下返回旧值还是新值？看 new 参数
这个布尔参数 new 控制着返回内容是更新前的快照（new: false，默认值），还是更新后的结果（new: true）。但必须明确一点：它只影响响应体里装的是什么，完全不影响操作的原子性。不少人误以为设为 true 就更安全，其实只是读到数据的时间点晚了一步而已。
new: false（默认）：返回的是加锁瞬间的文档快照。哪怕你在update里改了十个字段，返回的文档里也看不到这些变更。new: true：返回的是更新提交后的最终状态。这里有个细节：如果更新用的是$inc（递增），返回的就是递增后的值；如果是$setOnInsert，那只有确实发生了 upsert 插入时，这些字段才会生效并返回。- 事务中的陷阱：在事务里别盲目设
new: true。因为事务中的多个操作共享一个快照视图，此时new: true返回的，也只是该操作局部视角下的“新”，并非整个事务提交后的全局新状态。
真正要防并发冲突？靠唯一索引 + upsert
当你需要确保“只有一个客户端能创建某条记录”时，比如实现分布式锁的key，或者处理幂等性请求ID，用 findAndModify 反而是绕了远路。更轻量、更明确的方案是：唯一索引 + 直接插入。
- 建立索引：
db.jobs.createIndex({ jobId: 1 }, { unique: true }) - 尝试插入：
db.jobs.insertOne({ jobId: "abc123", createdAt: new Date() }) - 处理结果：如果抛出
E11000 duplicate key error错误，说明记录已存在，立刻重试或降级处理；如果没报错，恭喜，资源抢到了。
这套方案比 findAndModify 少了一次网络往返，更重要的是，它彻底避免了“查询时存在，但更新前被别人抢先”的竞态窗口。
说到底，并发控制从来不是选对一个函数就能高枕无忧的事情。findAndModify 的适用边界其实很窄：单文档操作、需要强顺序性、且必须返回中间状态。一旦超出这个范围，强行套用，反而可能掩盖了系统中真实的数据竞争点。
