mongodb事务中bulkwrite()必须传入显式session且禁用writeconcern，upsert行为受acid保护，失败则全回滚、成功则全提交。
在 MongoDB 事务中执行批量 upsert，bulkWrite() 必须配合显式 session 使用，且不能手动设置 writeConcern —— 否则会报错 Cannot specify write concern in transaction。
事务内调用 bulkWrite() 的硬性要求
事务中的 bulkWrite() 不是“把普通写法包进 with_transaction() 就行”，它有三处必须对齐的约束：
-
bulkWrite()调用时必须传入session参数，且该session必须来自同一MongoClient并已通过start_session()创建 - 不能在
bulkWrite()的 options 中传writeConcern（哪怕设为{w: 1}也不行），否则直接抛OperationFailure - 所有操作（
updateOne、replaceOne等）中若用upsert: true，其行为完全受事务控制：失败则全部回滚，成功则全部提交
PyMongo 示例：带 upsert 的有序批量写入（事务内）
以下是在 PyMongo 中安全执行的最小可行代码，注意 session 的生命周期和参数剥离：
with client.start_session() as session:
def callback(session):
result = collection.bulkWrite([
{"updateOne": {
"filter": {"_id": "user_1001"},
"update": {"$set": {"status": "active", "last_login": datetime.utcnow()}},
"upsert": True
}},
{"updateOne": {
"filter": {"email": "test@example.com"},
"update": {"$inc": {"login_count": 1}},
"upsert": True
}}
], session=session) # ← 这里传 session，但不传 writeConcern
print(f"Upserted: {result.upserted_count}, Modified: {result.modified_count}")
<pre class="brush:php;toolbar:false;"><code>session.with_transaction(callback)</code>
关键点：session 是唯一必需的额外参数；ordered=True（默认）可确保操作按序执行，适合依赖前序 upsert 结果的场景（比如先插用户再插其配置）。
为什么 ordered=False 在事务中要格外小心
虽然 ordered=False 能让失败的单个操作不中断整体流程，但它在事务中有两个隐性代价：
- 事务的原子性被“表面化”——即使部分
upsert失败，只要没抛出异常，事务仍可能成功提交，而你只能靠result.upserted_ids和result.upserted_count去反查哪些生效了 - 无法保证跨操作的逻辑顺序。例如你期望先
insertOne主文档、再updateOne关联子文档，设ordered=False可能导致后者因主文档未就位而静默失败 - 错误信息藏在
result.bulk_write_result的writeErrors字段里，不是顶层异常，容易漏处理
upsert 操作在事务中真正生效的边界
事务里的 upsert 不是“单独生效”，它的可见性完全绑定于事务生命周期：
- 事务未提交前，其他会话查不到任何 upsert 的数据（即使查的是同一个
_id） - 如果事务中某个
updateOnewithupsert: true匹配到已有文档，它走的是 update 分支；若没匹配到，则走 insert 分支 —— 两条路径在事务内都受 ACID 保护 - 不要在事务内混用
bulkWrite()和单条insert_one()，尤其当它们操作同一字段（如_id）时，可能触发重复键冲突，且错误定位困难
最易被忽略的一点：事务中 bulkWrite() 的性能并不比单条操作高多少，因为网络往返省不了（事务本身要发 commitTransaction 或 abortTransaction），真正收益在于数据一致性，而非吞吐量。
