连接池本身不导致死锁，但配置不当会放大死锁影响；真正死锁发生在数据库层，源于行锁竞争与加锁顺序不一致，如AB-BA循环等待。
连接池本身不会导致数据库死锁，但配置不当会放大死锁影响、掩盖真实问题——真正死锁永远发生在数据库层（MySQL/PostgreSQL 的行锁竞争），而连接池不合理会让错误表现得像“卡死”或“全 goroutine 睡眠”。
为什么调大 SetMaxOpenConns 反而更容易触发死锁？
连接数不是越多越好。当 SetMaxOpenConns 过高（比如设为 500），大量并发事务同时持锁、等待锁，会显著延长锁持有时间窗口，提高 AB-BA 循环等待概率。尤其在 RR 隔离级别下，间隙锁（Gap Lock）会让看似不相关的插入/更新也卷入死锁链。
- 默认值（0，即无限制）最危险：可能耗尽数据库连接上限，引发连接拒绝或隐式排队
- 推荐值 = 数据库侧
max_connections× 0.6～0.8，并预留至少 20% 给后台任务和监控 - 必须配合
SetConnMaxLifetime（建议 1h）和SetMaxIdleConns（建议 ≤SetMaxOpenConns的 1/3）防止 stale connection 和连接泄漏
db.Transaction 内部是否复用连接？会影响死锁吗？
会复用，且这是关键点。GORM 的 db.Transaction 默认从连接池取一个连接并全程独占，直到 Commit() 或 Rollback()。这意味着：事务越长，该连接上的锁持有时间越长，其他 goroutine 就越可能在同一批数据上撞出死锁。
- 避免在事务内做 HTTP 调用、文件 IO、sleep 或复杂计算
- 把非原子性操作（如发消息、写日志）移出
Transaction回调，改用异步或事务后钩子 - 如果必须跨服务协调，用最终一致性 + 补偿事务，别硬塞进 DB 事务
如何判断是连接池瓶颈还是真死锁？看这三类错误信号
别只盯着 panic 或超时。真实死锁有唯一可识别的数据库原生错误标识，和连接池问题完全不同：
- 死锁信号：
"Deadlock found when trying to get lock"（MySQL）、"ERROR: deadlock detected"（PostgreSQL，错误码40P01）——必须出现在tx.Commit().Error或查询 error 中 - 连接池打满信号：
"sql: database is closed"、"dial tcp: i/o timeout"、"context deadline exceeded"（且无 SQL 执行日志） - 锁等待超时信号：
"Lock wait timeout exceeded"（MySQL）、"canceling statement due to lock timeout"（PG）——这不是死锁，是单边等待被强制中断
开启 GORM Logger 并设为 Info 级别，确保每条 SQL 和 error 都落盘；否则你根本分不清是网络断了、连接枯竭，还是数据库真杀了你的事务。
并发写同一组 ID 时，GORM 怎么保证加锁顺序一致？
GORM 不自动排序 WHERE 条件，也不干预 SQL 生成顺序。如果你的业务逻辑里存在「先查 A 再查 B」和「先查 B 再查 A」两种路径，死锁就几乎必然发生。必须由你显式控制顺序：
- 对涉及多记录的事务，统一按主键升序加锁：
ids := []uint{2, 1}; sort.Slice(ids, func(i, j int) bool { return ids[i] - 用
Clauses(clause.Locking{Strength: clause.LockingStrengthUpdate})替代过时的Set("gorm:query_option", "FOR UPDATE") - WHERE 条件务必命中索引——全表扫描会升级为表锁，让所有并发写都堵在一张表上
最容易被忽略的是：即使你代码里写了排序，如果数据库执行计划没走索引，InnoDB 仍可能对不同事务加锁不同范围。每次上线前，用 EXPLAIN 检查关键 SELECT FOR UPDATE 的 type 和 key 字段。
