Fiber中事务无法自动回滚的主因是事务生命周期未与HTTP请求上下文对齐，导致panic时defer tx.Rollback()不执行；须用中间件通过ctx.Locals注入*sql.Tx，并在recover和error时显式回滚。
Fiber 中事务无法自动回滚的常见原因
在 Fiber 应用里调用 db.Transaction() 后，即使 handler 内 panic 或显式 tx.Rollback()，数据库仍可能提交成功——这不是 Fiber 的 bug，而是事务生命周期没和 HTTP 请求上下文对齐。
根本问题在于：Fiber 默认不提供事务中间件的上下文绑定机制，tx 对象若仅作为局部变量存在，panic 发生时它早已脱离作用域，defer tx.Rollback() 根本不会执行。
- 未用
ctx.Locals或自定义中间件把tx注入请求上下文 - 在异步 goroutine（如
go func(){}()）中操作事务，导致defer失效 - 错误地在
tx.QueryRow()后直接调用tx.Commit()，而没检查 error
用中间件统一管理事务生命周期
推荐在路由前插入事务中间件，用 ctx.Locals 存储 *sql.Tx，并在 panic 恢复后主动回滚。这是最可控的方式。
关键点：必须在 defer 里判断 tx != nil，且只在无 error 时 commit：
app.Use(func(c *fiber.Ctx) error {
tx, err := db.Begin()
if err != nil {
return c.Status(500).SendString("tx begin failed")
}
// 注入上下文，供后续 handler 使用
c.Locals("tx", tx)
defer func() {
if r := recover(); r != nil {
tx.Rollback()
panic(r)
}
}()
err = c.Next()
if err != nil {
tx.Rollback()
return err
}
tx.Commit()
return nil
})
- 所有 handler 内通过
c.Locals("tx").(*sql.Tx)获取事务对象 - 中间件必须在路由注册前调用，否则不生效
- 不要在中间件里
c.Send或c.Status，避免干扰后续逻辑
嵌套事务与 savepoint 的实际限制
Fiber 本身不支持嵌套事务，SQL 层面的 SAVEPOINT 需手动控制。PostgreSQL 和 MySQL 8.0+ 支持，但 SQLite 不支持。
如果你需要“部分回滚”，比如 A 操作失败不影响 B 提交，只能靠 savepoint：
tx, _ := db.Begin()
tx.Exec("SAVEPOINT sp1")
_, err := tx.Exec("INSERT INTO users ...")
if err != nil {
tx.Exec("ROLLBACK TO sp1") // 注意：不是 Rollback()
}
tx.Commit()
-
ROLLBACK TO SAVEPOINT不会终止事务，可继续Commit() - Fiber 中无法自动识别 savepoint 状态，必须业务代码显式管理
- MySQL 5.7 及更早版本不支持
SAVEPOINT在某些存储引擎下失效
并发请求下的事务隔离与连接泄漏风险
多个并发请求共用一个 *sql.DB 实例没问题，但每个请求必须有独立 *sql.Tx。若误将 tx 存为全局变量或复用，会导致数据错乱或死锁。
容易被忽略的一点：db.SetMaxOpenConns(n) 要大于预期并发事务数，否则 db.Begin() 会阻塞甚至超时：
- 默认
MaxOpenConns = 0（不限制），但操作系统级文件描述符可能先耗尽 - 使用
tx.Stmt()预编译语句时，需确保tx未被 commit/rollback，否则 panic - handler 返回前未调用
tx.Commit()或tx.Rollback()，连接会一直占用直到 GC 回收（不可依赖）
事务控制的真正难点不在语法，而在明确“谁负责开启、谁负责结束、panic 时是否还能触达 tx 对象”——这三个问题没理清，写再多 Rollback() 都是徒劳。
