Beego本身不处理死锁，真正死锁发生在底层数据库；需通过错误码（MySQL 1213、PostgreSQL 40P01）和SQL执行顺序统一、索引优化、事务显式提交及幂等重试来规避。
Beego 框架本身不处理死锁，真正发生死锁的是底层数据库（如 MySQL/PostgreSQL），而 Beego 的 orm 或直连 database/sql 会把错误原样透传上来。你看到的卡顿、HTTP 超时、甚至 fatal error: all goroutines are asleep - deadlock!，大概率是数据库死锁导致事务阻塞，而非 Go 运行时真死锁。
如何从 Beego 日志里快速定位死锁错误
Beego 默认不会自动解析 SQL 错误码，必须主动检查返回的 error 内容。死锁在数据库层有明确标识：
- MySQL：错误信息包含
"Deadlock found when trying to get lock"，错误码为1213 - PostgreSQL：错误码是
"40P01"（对应deadlock_detected），需用pgerr.Code提取（若用github.com/lib/pq） - Beego 的
orm.Debug = true可打印 SQL，但不捕获错误类型；必须在o.Read()、o.Update()、o.Insert()等调用后立即检查err
别依赖日志关键词搜索“deadlock”——有些生产环境会关闭详细错误输出，建议统一包装数据库操作，强制校验错误类型。
Beego ORM 中多表更新顺序不一致引发死锁
Beego 的 orm.QuerySeter 不保证加锁顺序，尤其在批量更新或关联模型操作中容易踩坑。例如两个事务分别执行：
// 事务 A（按 user_id 升序）
o.QueryTable("transfer").Filter("from_user_id", 100).Filter("to_user_id", 200).Update(orm.Params{"status": 2})
<p>// 事务 B（按 to_user_id 先查）
o.QueryTable("transfer").Filter("to_user_id", 200).Filter("from_user_id", 100).Update(orm.Params{"status": 2})
如果底层没有索引支撑，或 WHERE 条件触发不同扫描路径，就可能让 InnoDB 对同一组行加锁顺序相反，形成 AB/BA 循环等待。解决方法：
- 所有涉及同一业务实体的更新，强制统一 WHERE 条件顺序（如始终先
from_user_id后to_user_id） - 给常用查询字段组合建联合索引，避免全表扫描导致不可控锁范围
- 避免在 Beego Controller 中直接调用多次
o.Update()；应合并为单次原子操作，或下沉到 Service 层统一控制锁粒度
Beego 中事务未显式提交/回滚导致连接池耗尽
这不是数据库死锁，但常被误认为死锁：Beego 使用 orm.RunTransaction() 开启事务后，若 panic 或忘记 return，事务不会自动关闭，连接被长期占用。当连接池满（如 SetMaxOpenConns(10)），后续请求全部阻塞在 db.GetConn()，表现为“所有接口变慢+超时”，和死锁现象高度相似。
- 务必在
RunTransaction的函数体末尾显式return nil或return err，不能靠 defer - 不要在事务函数内启动 goroutine 并复用
orm.Ormer实例——Beego 的Ormer不是并发安全的 - 用
defer fmt.Printf("tx done\n")类似方式临时打点，确认事务函数是否真实退出
Beego 场景下重试逻辑必须幂等且下沉到 Service 层
在 Controller 里写 for 循环重试死锁是危险的：HTTP 请求上下文可能已超时，重试只会放大压力。正确做法是把重试封装进 Service 方法，并确保每次重试不产生副作用：
- 重试前用
time.Sleep指数退避（如第 1 次 10ms、第 2 次 30ms、第 3 次 100ms） - 禁止在重试逻辑里调第三方 API、发 MQ 消息、写文件——这些操作必须放在事务成功提交之后
- 对转账类操作，用
SELECT ... FOR UPDATE ORDER BY id ASC显式加锁并排序，破坏循环等待条件；Beego ORM 不支持原生ORDER BY加锁，需改用Raw()执行
最易被忽略的一点：Beego 的 orm.Debug = true 在生产环境开启后，SQL 日志会严重拖慢性能，且掩盖真实锁等待时间。排查阶段可开，验证修复后务必关掉。
