面试官写下两条 SQL：先扣 A，再给 B 加钱。每条 UPDATE 单独执行都没问题，为什么 A 转 B 与 B 转 A 同时发生时会死锁？
如果只回答“数据库锁冲突”，还不够。高分答案要把两个事务的时间线画出来，并继续说明怎样修、怎样重试、怎样验证资金没有被重复移动。
死锁发生在事务之间
事务 T1 先锁账户 A，准备再锁 B；事务 T2 先锁 B，准备再锁 A。T1 等 T2 释放 B，T2 又等 T1 释放 A，等待图形成环。数据库通常会检测这个环，选择回滚其中一个事务，让另一个继续。
所以日志里可能看到的不是永久卡死，而是一个事务收到 deadlock detected 或 deadlock victim。应用若把它当普通 500 返回，用户就会觉得转账随机失败。
最直接的修复：统一锁顺序
无论资金从谁转给谁，都按 account_id 从小到大获取锁。A 转 B 与 B 转 A 会争抢同一个第一把锁，其中一个等待，但不会形成环。
BEGIN;
SELECT account_id, balance
FROM account
WHERE account_id IN (:from_id, :to_id)
ORDER BY account_id
FOR UPDATE;
UPDATE account
SET balance = balance - :amount
WHERE account_id = :from_id
AND balance >= :amount;
UPDATE account
SET balance = balance + :amount
WHERE account_id = :to_id;
INSERT INTO transfer_ledger(request_id, from_id, to_id, amount)
VALUES (:request_id, :from_id, :to_id, :amount);
COMMIT;
应用必须检查扣款 UPDATE 是否影响一行，否则余额不足时不能继续入账。transfer_ledger 的 request_id 应唯一，防止客户端或死锁重试重复转账。
为什么“捕获异常后重试”也可能出错
若应用每次重试都生成新的 request_id，第一次事务其实已提交但响应丢失时，第二次会再次转账。重试必须复用同一业务键，并只针对明确可重试错误，例如数据库报告的死锁或短暂锁等待超时。
退避也要有限，避免高冲突时所有线程立即重试形成新一轮碰撞。超过次数后返回可查询状态，让用户按 request_id 查最终结果。
import random
import time
def transfer_with_retry(service, command, max_attempts=3):
for attempt in range(max_attempts):
try:
return service.transfer(command) # command.request_id 始终不变
except service.DeadlockError:
if attempt == max_attempts - 1:
raise
time.sleep(0.02 (2 ** attempt) + random.random() 0.01)
自动化测试要主动制造等待环
普通并发压测不一定稳定复现。测试可以用 Barrier 控制两个事务：T1 锁 A 后暂停，T2 锁 B 后暂停，再让两边同时请求第二把锁。这样每次都能命中目标时序。
修复统一顺序后，继续跑相同实验，预期不再形成等待环；可能有一个事务短暂等待，但两者最终只有成功或明确余额不足。
最后用业务不变量收口
无论发生死锁、回滚还是重试，两个账户总余额保持不变；每个 request_id 最多一条成功流水；流水金额与账户差额一致；任何中间失败都不能出现只扣不加。
面试时可以按这个顺序回答：画等待环，说明数据库会回滚一个事务；用固定资源顺序预防；缩短锁持有时间；仅对可重试错误有限重试；用幂等键与余额对账保护终态。
如果你正在准备测试开发校招，这类题不要只背“死锁四条件”。通过 Python 全栈开发与自动化测试项目，亲手控制两个事务的交错并查询锁等待，你会真正理解并发测试为什么比单接口断言更难。
两条 UPDATE 的正确性，只属于各自的单线程世界；转账是否正确，要在事务交错、失败回滚和重试之后看最终资金账。
