Motor本身不支持跨集合事务，必须用AsyncIOMotorClient显式启动会话并传入session参数，所有操作需在with_transaction()回调中执行且严格遵循分片键约束、读关注限制及60秒超时规则。
Motor 本身不支持跨集合事务，必须用 AsyncIOMotorClient 启动会话
Motor 是异步驱动，但它的事务能力完全依赖底层 MongoDB 的 start_session() 和 with_transaction()，不是靠封装函数自动实现的。直接对多个 collection.insert_one() 连续调用，哪怕在同一个 async with 块里，也**不是事务**——MongoDB 会当作独立操作执行，失败时无法回滚。
正确做法是显式创建会话，并传入 with_transaction() 回调：
async def transfer_money(session):
await db.accounts.update_one(
{"_id": "alice"}, {"$inc": {"balance": -100}}, session=session
)
await db.transactions.insert_one(
{"from": "alice", "to": "bob", "amount": 100}, session=session
)
await db.accounts.update_one(
{"_id": "bob"}, {"$inc": {"balance": 100}}, session=session
)
async with await client.start_session() as session:
await session.with_transaction(transfer_money)
注意三点：
• 所有涉及集合的操作都必须显式传入 session 参数；
• with_transaction() 自动处理重试（仅限可重试错误），但不捕获业务逻辑异常；
• 回调函数必须是协程，且不能带额外参数（只能接受 session）。
事务只在单个副本集或分片集群中生效，跨分片事务有严格限制
如果你的集合分布在不同分片上，MongoDB 要求所有参与事务的文档必须能通过分片键路由到同一分片——否则会报错 TransactionNumbersMismatch 或 ShardKeyNotFound。Motor 不会提前校验这点，错误只在 commitTransaction 阶段暴露。
立即学习“Python免费学习笔记（深入）”；
常见踩坑点：
- 没给集合设置分片键，却部署在分片集群上 → 事务默认被拒绝
- 两个集合分片键不同（比如一个按
user_id分片，另一个按order_id）→ 即使逻辑相关，也无法加入同一事务 - 查询条件未包含分片键（如
find({"status": "pending"})）→ 可能广播到所有分片，导致事务失败
验证方式：连接后执行 await client.admin.command("shardingState") 看是否启用了分片，再查各集合的 shard key 是否一致。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
事务内不能使用某些操作，比如集合创建、索引修改、读关注设为 majority 外的值
MongoDB 事务有明确禁用列表，Motor 执行时若违反，会在 commitTransaction 时报 InvalidOptions 或 IllegalOperation。典型不可用操作包括：
-
db.create_collection()和db.drop_collection() -
create_index()、drop_index() -
distinct()（除非指定read_concern="majority"） - 任何非
majority的read_concern（如"local"或"available"）
尤其要注意：Motor 默认读关注是 "majority"，但如果你手动设置了 read_preference=ReadPreference.NEAREST，就可能触发失败。事务内所有操作应保持默认读关注，不要覆盖。
超时和锁等待容易被忽略，长事务会导致连接堆积和写冲突
MongoDB 事务默认最大运行时间是 60 秒（transactionLifetimeLimitSeconds），Motor 不提供单独配置项，必须通过客户端连接字符串或服务端参数调整。超过时限会自动 abort，抛出 ExecutionTimeout。
更隐蔽的问题是锁竞争：事务期间对文档加的是“文档级锁”，但如果多个事务频繁更新同一文档（比如高并发扣库存），会出现 WriteConflict 错误——Motor 会自动重试（最多 5 次），但重试失败后仍抛异常，业务层需捕获并决定是否降级（如转为补偿事务）。
建议做法：
- 事务体尽量短，避免 I/O、网络请求、复杂计算
- 更新前先用
find_one_and_update(..., upsert=False)检查存在性，减少空写冲突 - 监控
currentOp中"secs_running" > 30的事务，及时告警
真正难调试的从来不是语法，而是事务边界是否真覆盖了所有写路径，以及分片键设计是否让逻辑相关的数据落在同一物理位置。
