Buffalo 的 Pop ORM 不自动重试 MySQL 死锁，需手动实现：检查 err.(*mysql.MySQLError).Number == 1213，配合 for 循环、指数退避、每次新建事务并正确提交/回滚。
Buffalo 本身不内置数据库死锁重试逻辑，Pop 作为其默认 ORM，也不会自动捕获并重试死锁异常。你得自己加一层兜底 —— 否则遇到 Deadlock found when trying to get lock 就直接抛给上层，事务回滚，用户看到 500。
Pop 中识别 MySQL 死锁错误码
MySQL 死锁触发时返回的 SQLSTATE 是 40001，错误信息里通常含 "Deadlock found when trying to get lock"。Pop 抛出的错误类型是 <em>pop.Error</em>（底层是 mysql.MySQLError），但不能只靠 error message 字符串匹配 —— 容易误判。
- ✅ 正确做法：检查
err.(*mysql.MySQLError).Number是否等于1213（MySQL 官方死锁错误码） - ❌ 避免：用
strings.Contains(err.Error(), "Deadlock")—— 日志脱敏、多语言环境、中间件包装后可能丢失关键词
if me, ok := err.(*mysql.MySQLError); ok && me.Number == 1213 {
// 是死锁，可重试
}
在 Pop 事务中手动实现有限重试
Pop 没有类似 Spring Retry 的声明式注解，重试必须显式写在业务逻辑里。常见模式是：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 用 for 循环 + 最大重试次数（比如 3 次）
- 每次失败后
time.Sleep指数退避（如 50ms → 100ms → 200ms） - 每次都新建
*pop.Connection或至少新开tx（不能复用已失败的事务）
- 重试前必须
tx.Close()或让 defer 清理掉旧事务，否则会 panic："transaction has already been committed or rolled back" - 不要在重试循环里共用同一个
tx实例 —— 一旦tx.Rollback()或隐式失败，该tx就不可再用 - 所有数据库操作（
tx.Find()、tx.Create()等）必须放在每次循环内重新执行，不能把“查出来再改”这种两阶段操作拆到循环外
Buffalo Handler 中嵌入重试逻辑的典型结构
你通常在 actions/*.go 文件的 handler 里操作数据库。建议把重试封装成一个闭包或小函数，避免重复代码：
func withDeadlockRetry(maxRetries int, fn func(tx *pop.Connection) error) error {
var lastErr error
for i := 0; i <= maxRetries; i++ {
tx, err := db.Transaction()
if err != nil {
return err
}
if i > 0 {
time.Sleep(time.Duration(50*math.Pow(2, float64(i-1))) * time.Millisecond)
}
lastErr = fn(tx)
if lastErr == nil {
return tx.Commit()
}
tx.Rollback()
if me, ok := lastErr.(*mysql.MySQLError); ok && me.Number == 1213 && i < maxRetries {
continue
}
return lastErr
}
return lastErr
}
<p>// 使用示例
func (h Actions) UpdateUser(c buffalo.Context) error {
return withDeadlockRetry(2, func(tx *pop.Connection) error {
u := &models.User{ID: 123}
if err := tx.Find(u, u.ID); err != nil {
return err
}
u.Name = "new name"
return tx.Update(u)
})
}</p>死锁重试不是万能的，它只适用于读-改-写且幂等可重放的操作。如果事务里混了外部 HTTP 调用、发 MQ、改 Redis，重试就可能引发重复副作用 —— 这类场景得靠补偿事务或最终一致性设计，而不是靠 Pop 层重试兜底。
