死锁根因是事务加锁顺序不一致或索引失效，非GORM框架导致；需通过SHOW ENGINE INNODB STATUS\G定位LATEST DETECTED DEADLOCK段，结合SQL、HOLDS/WAITING锁信息及lock_mode分析，并确保WHERE条件命中索引、统一加锁顺序、控制事务粒度。
事务死锁不是GORM的问题，是SQL执行顺序和索引设计冲突的结果
死锁在GORM里高频出现，往往不是框架本身导致的，而是多个事务以不同顺序访问同一组行（比如先更新A再更新B，另一个事务先更新B再更新A），而数据库无法判断谁该让步，最终触发死锁检测并回滚其中一个。GORM只是把你的代码逻辑翻译成SQL，真正决定加锁范围、锁粒度、锁顺序的是你写的Where条件、Update字段、是否命中索引，以及事务内操作的先后顺序。
排查第一步永远不是看GORM日志，而是抓出死锁日志本身——MySQL用SHOW ENGINE INNODB STATUS\G，里面LATEST DETECTED DEADLOCK段会明确列出两个事务各自持有的锁、等待的锁、执行的SQL语句。没有这一步，所有“调大超时”“加重试”都是蒙眼优化。
为什么Preload + Update组合最容易引发死锁
常见场景：一个事务里先Preload("Orders")查出用户+订单列表，再遍历每个订单做tx.Model(&Order{}).Where("id = ?", o.ID).Update("status", "shipped")。表面看是读+写，但Preload默认走JOIN或子查询，如果没加FOR UPDATE或没显式控制隔离级别，InnoDB可能对订单表加间隙锁（gap lock）；而后续的Update又会对同一行加记录锁（record lock）。两个锁叠加+并发时顺序不一致，就容易撞上死锁。
- 避免在同一个事务里混用“全量预加载”和“逐条更新”，尤其当Preload没加条件过滤时，等于提前锁了一大片无关数据
- 把读和写拆开：先用
SELECT id FROM orders WHERE user_id IN (?) FOR UPDATE只锁ID，再批量Update，减少锁持有范围 - 确保Where条件始终走索引——
WHERE status = 'pending'如果status没索引，InnoDB会升级为表锁或大量间隙锁，死锁概率指数级上升
索引缺失或失效是死锁温床，三类必须检查的索引
死锁常发生在高并发更新热点行时，而索引决定了数据库能不能快速定位到那几行，而不是扫全表去加一堆无效锁。以下三类索引一旦缺失，几乎必然伴随死锁增长：
-
UPDATE或DELETE语句的WHERE字段必须有单列或复合索引，例如UPDATE orders SET status = ? WHERE user_id = ? AND status = ?，对应索引应为(user_id, status)，顺序不能反 - 外键字段必须建索引，否则
ON DELETE CASCADE或关联查询时，InnoDB会隐式锁整个父表 - 排序+分页场景的
ORDER BY ... LIMIT，若ORDER BY字段无索引，数据库要先排全表再取前N条，过程中锁住大量中间结果，极易与其它事务冲突
验证方式很简单：EXPLAIN你的Update/Delete语句，看key列是否显示用了索引，rows是否明显小于表总行数。如果显示type: ALL或key: NULL，索引就是废的。
事务粒度失控比慢SQL更危险
很多死锁不是因为SQL写得差，而是事务包了太多不该包的东西。比如在事务里调第三方API、发邮件、处理文件IO，这些操作耗时不可控，导致锁持有时间从毫秒级拉长到秒级，其它事务排队等待时撞锁概率陡增。
- 事务里只做数据库变更，所有外部依赖移出去
- 避免在事务中做循环体内的多次DB操作，能合并就合并：
db.Where("id IN ?", ids).Updates(map[string]interface{}{"status": "done"})比100次单条Update安全得多 - 给事务加
context.WithTimeout，比如tx := db.WithContext(ctx).Begin()，超时自动回滚，防止长事务拖垮整个连接池
最常被忽略的一点：GORM事务默认使用数据库默认隔离级别（MySQL是REPEATABLE READ），这个级别下间隙锁行为复杂，对业务逻辑理解要求高。如果业务允许，可考虑在事务开始时显式降级：tx.Exec("SET TRANSACTION ISOLATION LEVEL READ COMMITTED")，能大幅减少间隙锁冲突，代价是可能读到已提交的脏数据——但多数订单/库存场景里，这比死锁更可控。
