结论：不加控制的并发更新必然覆盖，核心解法是用原子操作（如$inc、$setOnInsert）+乐观锁（如version字段），而非应用层“先查后改”；updateOne本身原子，但无法解决“读-改-写”三步竞态。
直接说结论：不加控制的并发更新必然覆盖，核心解法是用原子操作 + 乐观锁，而不是靠应用层“先查后改”。
为什么update_one()默认不是线程安全的？
MongoDB 的 update_one() 本身是原子的，但“原子”只保证单次操作内部不被打断——它不解决“读-改-写”这个三步动作的竞态。典型错误写法：
doc = collection.find_one({"_id": 1})
new_value = doc["counter"] + 1
collection.update_one({"_id": 1}, {"$set": {"counter": new_value}})两个线程同时执行这段代码，都读到 counter=5，都算出 6，最后结果还是 6，不是预期的 7。
- 这不是 PyMongo 的 bug，是应用逻辑缺陷
- 哪怕用了
threading.Lock，在高并发下也会成为性能瓶颈 - 真正该做的是把“读+算+写”压缩成一条原子命令
用 $inc、$setOnInsert 等原子操作符替代手动计算
绝大多数覆盖问题，其实根本不需要先读再改。比如计数、状态标记、追加日志，直接交给 MongoDB 原子操作：
立即学习“Python免费学习笔记（深入）”；
- 计数器累加：
collection.update_one({"_id": 1}, {"$inc": {"counter": 1}}) - 首次设置字段（避免覆盖已有值）：
collection.update_one({"_id": 1}, {"$setOnInsert": {"created_at": datetime.now()}}, upsert=True) - 追加数组元素（不重复）：
collection.update_one({"_id": 1}, {"$addToSet": {"tags": "urgent"}}) - 仅当当前值匹配时才更新（乐观锁基础）：
collection.update_one({"_id": 1, "version": 5}, {"$set": {"data": "new", "version": 6}})
这些操作全部由服务端完成，客户端不参与中间状态，天然规避覆盖。
需要复杂逻辑时，用 find_one_and_update() + version 字段
如果真要基于当前文档内容做条件判断（比如“只有 price
- 给文档加一个
version字段，每次更新都递增 - 用
find_one_and_update()一次性完成“读+条件判断+更新+版本升序” - 检查返回值：如果返回
None，说明条件不满足或已被别人抢先更新，需重试
示例：
result = collection.find_one_and_update(
{"_id": 1, "price": {"$lt": 100}, "version": 3},
{"$set": {"discounted": True}, "$inc": {"version": 1}},
return_document=ReturnDocument.AFTER
)
if result is None:
# 要么 price >= 100，要么 version 已变 → 重试或放弃注意：find_one_and_update() 是原子的，但重试逻辑必须由你实现，不能指望它自动循环。
别碰 replace_one()，也别在多线程里共享 MongoClient 实例却不配连接池
replace_one() 是全文档替换，和 update_one() + $set 完全不是一回事，一用就覆盖——除非你明确想丢掉所有旧字段。
更隐蔽的坑是连接池配置：
- 每个线程都新建
MongoClient→ 连接数爆炸 →Connection refused或超时，看似是并发问题，实则是资源耗尽 - 正确做法：全局单例 + 显式设
maxPoolSize=50、minPoolSize=5、socketTimeoutMS=5000 - 没配这些，
update_one()再原子也卡在连不上库上
并发更新的复杂点不在语法，而在你是否意识到：MongoDB 不是内存变量，它的“一致性”必须由你用操作符、条件、版本号去主动声明，而不是靠 Python 里的 if/else 去模拟。
