Beego框架中需主动识别MySQL错误码1213（或SQLSTATE '40001'）判断死锁，重试必须包裹整个事务并显式Rollback；优先统一SQL访问顺序、避免o.ReadOrCreate等易引发间隙锁的操作，结合orm.Debug日志与goroutine ID关联定位具体代码行。
Beego 框架本身不参与数据库锁的加/释放，死锁排查的关键不在 beego.Controller 或 orm.RegisterModel，而在于你用它调用的 SQL 是否存在并发冲突、事务边界是否清晰、以及是否暴露了底层死锁信号。
怎么从 Beego 日志里快速识别死锁发生
Beego 默认不会把 MySQL 的 ERROR 1213 (40001): Deadlock found when trying to get lock 自动标记为 ERROR 级别并打堆栈——它可能被 ORM 层吞掉或降级成 WARN。必须主动检查日志中是否出现该错误码。
- 在
conf/app.conf中确保loglevel = 4（Debug），否则orm.Debug开启后的 SQL 执行异常可能被忽略 - 开启 ORM SQL 日志：
orm.Debug = true，并在业务代码中用o.Begin()显式开启事务，避免隐式事务掩盖回滚点 - 搜索日志关键词：
Deadlock found、rollback、transaction begin，三者时间戳接近时基本可定位为一次死锁事件
Beego + XORM / ORM 层如何传递 rollbackFor 异常
Beego 自带的 ORM 不支持 @Transactional(rollbackFor = ...) 这类 Spring 风格声明，事务回滚完全依赖 Go 原生 error 判断。一旦 SQL 报 ERROR 1213，底层 database/sql 会返回 *mysql.MySQLError，但 Beego ORM 默认只检查 err != nil，不区分错误类型。
- 必须手动判断错误是否为死锁：
if mysqlErr, ok := err.(*mysql.MySQLError); ok && mysqlErr.Number == 1213 - 遇到死锁时，不要直接 return，而应重试（最多 2–3 次），因为 MySQL 已经回滚了触发死锁的事务，重试大概率成功
- 避免在
defer o.Rollback()里无条件执行——如果事务已因死锁被 DB 自动回滚，再次调用Rollback()会报sql: transaction has already been committed or rolled back
为什么 Beego 的事务嵌套容易放大死锁风险
Beego ORM 没有传播行为控制（如 REQUIRES_NEW），所有 Begin() 都是独立事务。但开发者常误以为“外层 Controller 方法包一个 Begin，内层 Service 再 Begin 就是嵌套”，结果变成多个并发事务争同一组行锁。
- 典型陷阱：两个 HTTP 请求同时调用同一接口，各自
o.Begin()→ 同时查SELECT ... FOR UPDATE WHERE id IN (1,2)→ 加锁顺序稍有差异（如索引扫描方向不同）→ 死锁 - 解决思路不是加锁粒度更细，而是统一访问顺序：对 IN 条件强制
ORDER BY id ASC，或改用主键逐条更新代替批量FOR UPDATE - 慎用
o.ReadOrCreate：它内部含 SELECT + INSERT ON DUPLICATE KEY，间隙锁（Gap Lock）极易在唯一索引上引发死锁，尤其在高并发插入场景
怎么用 Beego 结合 MySQL 死锁日志定位具体代码行
MySQL 的 SHOW ENGINE INNODB STATUS\G 输出里，WAITING FOR THIS LOCK 和 HOLDS THE LOCK(S) 对应的 SQL 是原始语句，但 Beego ORM 生成的 SQL 带占位符（如 WHERE id = ?），无法直接匹配。需要反向映射。
- 开启
orm.Debug = true后，每条 SQL 日志前会打印 goroutine ID 和调用栈文件名+行号，例如：[ORM] - [Queries/default] - [127.0.0.1:56892] [12345] model.go:88 - 把死锁日志里的 SQL 片段（如
UPDATE user SET balance = ? WHERE id = ?）和 Beego 日志中同 goroutine ID、相近时间戳的 Debug 行关联起来 - 重点检查那些在事务中调用了多次
o.QueryRow/o.Read后再o.Update的方法——这类“读-改-写”模式最容易因并发导致加锁顺序不一致
真正难处理的不是死锁本身，而是它在 Beego 里没有显式事务传播机制的情况下，会悄无声息地让部分请求重试失败、部分成功、部分超时，最终表现为接口成功率波动而非报错。盯住 mysql.MySQLError.Number == 1213 这个信号，比等告警更可靠。
