Flask本身不导致死锁，死锁源于数据库事务或线程锁使用不当；典型表现为请求卡在with_for_update()、acquire()等处，错误提示“Deadlock found when trying to get lock”或进程无响应。
Flask本身不直接导致死锁，死锁发生在底层数据库事务或线程锁使用不当的环节；典型表现是多个请求卡在with_for_update()、acquire()或数据库连接等待上，错误信息为Deadlock found when trying to get lock; try restarting transaction或进程无响应。
MySQL死锁1213不是隔离级别低引起的
很多人看到Deadlock found when trying to get lock就去调高isolation_level，但这是误区。MySQL的REPEATABLE READ（默认）加锁行为包含间隙锁（gap lock），两个事务若按不同顺序更新同一组行（比如A先改id=5再改id=3，B反过来），就会形成循环等待——跟隔离级别是否“够高”无关。
-
SQLALCHEMY_ENGINE_OPTIONS['isolation_level']只影响新连接的默认值，对已开启事务无效 - 盲目设成
SERIALIZABLE反而扩大锁范围，加剧争抢 - PostgreSQL的
REPEATABLE READ是快照隔离，不加间隙锁，死锁概率低得多；别拿PG经验套MySQL
Flask-SQLAlchemy中with_for_update()用错顺序就死锁
高并发订单/库存场景下，最常见死锁代码长这样：
inventory = Inventory.query.filter_by(product_id=pid).with_for_update().first() # 扣减库存 → 创建订单
问题在于：如果两个请求分别查product_id=101和product_id=102，而一个按101→102顺序锁，另一个按102→101，InnoDB立刻报1213。
立即学习“Python免费学习笔记（深入）”；
- 必须提前排序再批量锁：用
Inventory.query.filter(Inventory.product_id.in_([101, 102])).order_by(Inventory.product_id).with_for_update().all() - 避免在事务里分多次
with_for_update()——锁要一次锁全，不能“查一行、锁一行、再查下一行” - 加
nowait=True主动失败：.with_for_update(nowait=True)，抛DBAPIError比卡死更利于重试
多线程环境下Python锁顺序不一致也会卡住
如果你在Flask路由里手动用了threading.Lock（比如保护共享内存计数器），而多个请求线程以不同顺序获取两把锁，就会出现纯Python层死锁，现象是请求完全无响应、CPU空转、Ctrl+\能打出堆栈里一堆acquire阻塞。
- 永远不要写
with lock_a: with lock_b:和with lock_b: with lock_a:并存的逻辑 - 统一顺序：按锁对象
id()、变量名字符串排序，或预定义编号（如LOCK_ORDER = {'counter': 1, 'cache': 2}） - 不用
with语法糖，改用if not lock.acquire(timeout=2): raise RuntimeError("lock timeout")，并配try/finally: lock.release()
真正难排查的是混合型死锁：数据库锁 + Python线程锁 + 外部服务调用（比如扣库存后发MQ，而MQ客户端内部又用了锁）。这类问题不会报明确错误，只会让部分请求缓慢堆积、超时、最终拖垮整个连接池。盯住SHOW ENGINE INNODB STATUS输出里的LATEST DETECTED DEADLOCK段，再结合py-spy record -p PID看线程真实阻塞点，比猜配置有用得多。
