死锁主因是事务加锁顺序不一致，而非隔离级别过低；典型场景为事务A先锁id=101再锁id=102，事务B反之，形成循环等待，即使设为SERIALIZABLE也无法避免，反而因间隙锁扩大更易触发。
死锁不是隔离级别设低了才发生，而是加锁顺序不一致
MySQL报Deadlock found when trying to get lock; try restarting transaction（错误1213）时，别急着改isolation_level。这不是“隔离不够”，而是两个事务以相反顺序锁定同一组行：A先锁product_id=101再锁product_id=102，B反过来——立刻形成环路。哪怕你设成SERIALIZABLE，InnoDB照样死锁，甚至更频繁，因为间隙锁范围更大。
真正要盯的是业务代码里的锁路径：
- 检查所有带
with_for_update()或SELECT ... FOR UPDATE的查询，确认是否跨多个主键/索引值 - 看这些查询是否在不同请求中按不同顺序执行（比如前端传参顺序随机、列表过滤后未排序）
- 排查有没有在同一个事务里分多次调用
with_for_update()查不同条件（如先查库存再查用户余额）
多行更新必须强制统一主键升序加锁
涉及多个记录的写操作（如批量扣减库存、并发转账），不能靠ORM自动“查一个锁一个”。必须把待操作ID提前排序，一次性查全、锁全。
错误写法：
立即学习“Python免费学习笔记（深入）”；
for pid in [102, 101]: # 顺序不固定
inv = Inventory.query.filter_by(product_id=pid).with_for_update().first()
inv.stock -= 1
正确写法：
pids = sorted([102, 101]) # 强制升序
invs = Inventory.query.filter(Inventory.product_id.in_(pids)).order_by(Inventory.product_id).with_for_update().all()
for inv in invs:
inv.stock -= 1
关键点：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
order_by()必须作用于with_for_update()之前，否则排序无效 - 不要用
in_()后手动循环查——那会触发N+1次独立锁，顺序无法保证 - 如果ID来自用户输入或外部API，务必先
sorted()再进查询，别信“传进来就是有序的”
用with_for_update(nowait=True)主动失败，别等超时
默认with_for_update()会阻塞等待锁释放，卡住整个请求线程，既难定位又拖垮吞吐。加nowait=True让冲突立刻抛DBAPIError，配合重试更可控。
示例：
try:
inv = Inventory.query.filter_by(product_id=101).with_for_update(nowait=True).first()
except DBAPIError as e:
if "Lock wait timeout exceeded" in str(e) or "could not obtain lock" in str(e):
raise RetryException("Lock conflict, retry later")
raise
注意：
- PostgreSQL 和 MySQL 都支持
nowait=True，但SQLite不支持，线上环境需确认数据库类型 - 捕获异常时别只看错误码，MySQL 8.0+ 和旧版的提示字符串略有差异，建议同时检查
e.orig.args[0]（MySQL错误号） - 重试要用指数退避，别立刻重试，否则可能把死锁变成雪崩
isolation_level配置只影响新连接，事务中改不了
很多人在SQLALCHEMY_ENGINE_OPTIONS里写了'isolation_level': 'READ COMMITTED'，就以为所有事务都生效了——其实它只在连接池新建连接或从池中取出空闲连接时应用。已开启的事务、正在执行的db.session完全不受影响。
验证当前事务真实隔离级别，得绕过ORM直接查库：
- MySQL：
SELECT @@transaction_isolation（8.0+）或SELECT @@tx_isolation（5.7） - PostgreSQL：
SHOW TRANSACTION ISOLATION LEVEL - 必须在
session.begin()之后、执行业务SQL之前查，否则返回的是会话默认值
真正难处理的场景，是当触发器、存储过程或另一个服务直连数据库修改了同一张表——这时SQLAlchemy日志里根本看不到锁来源。这时候翻INFORMATION_SCHEMA.INNODB_TRX（MySQL）或pg_locks（PostgreSQL）比调配置管用得多。
