fiber中间件仅支持请求校验，无法自动回滚数据库操作；回滚必须由业务代码在handler中显式调用tx.rollback()实现，且需使用带context的db方法确保事务可控。
Fiber 是 Go 语言的轻量级 Web 框架，本身不提供事务管理或数据库回滚能力——它既没有 Spring Boot 那样的 @Transactional 机制，也不内置 ORM 或事务上下文传播。所谓「在中间件中实现请求数据校验 + 回滚」，本质是混淆了两个独立关注点：
- 校验（Validation）：拦截请求、检查参数合法性，失败则提前终止
-
回滚（Rollback）：只存在于数据库事务语义中，需底层驱动支持（如
pgx、sqlx+BeginTx），且必须由业务代码显式控制
中间件无法“自动回滚”已执行的 DB 操作，它只能决定「是否放行请求」。真要实现「校验失败就撤销已写库行为」，得靠手动事务控制，不是中间件能代劳的。
Fiber 中间件里做参数校验的正确姿势
Fiber 的中间件（func(*fiber.Ctx) error）适合做前置校验，但要注意：
- 校验失败必须调用
c.Status(400).JSON(...)并 显式 return，否则后续 handler 仍会执行 - 不要试图在中间件里调用
c.Next()后再“撤回”DB 写入——这违反中间件设计原则，也做不到 - 常见错误：在中间件里解析 JSON 成 struct 并校验，但没处理指针/零值陷阱
示例（使用 go-playground/validator）：
func ValidateUser(c *fiber.Ctx) error {
var req struct {
Name string `validate:"required,min=2,max=20"`
Email string `validate:"required,email"`
}
if err := c.BodyParser(&req); err != nil {
return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "解析失败"})
}
if err := validator.New().Struct(req); err != nil {
return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": err.Error()})
}
// ✅ 校验通过，才把数据挂到上下文供后续 handler 用
c.Locals("validatedUser", req)
return c.Next() // 放行
}
真正需要“校验失败就回滚”的场景，该怎么写？
这不是中间件的事，是 handler 里的事务控制逻辑。典型结构：
- 在 handler 开头调用
db.BeginTx() - 执行校验（可复用上面中间件的逻辑，或直接在 handler 里做）
- 校验失败 → 调用
tx.Rollback()→ 返回错误 - 校验成功 → 执行 DB 操作 →
tx.Commit()
关键点：
-
tx必须传递给所有涉及 DB 的函数（不能依赖全局 DB 句柄） - 不要用
defer tx.Rollback()，它会在函数结束时无条件触发，掩盖成功路径 - 若用
sqlx，注意tx.Stmt()和tx.Get()/tx.Select()才走事务
简略示意：
func CreateUser(c *fiber.Ctx) error {
tx, err := db.BeginTx(c.Context(), nil)
if err != nil { return c.Status(500).SendString("tx begin failed") }
var req UserReq
if err := c.BodyParser(&req); err != nil || !req.IsValid() {
tx.Rollback() // ❗必须主动 rollback
return c.Status(400).JSON(fiber.Map{"error": "invalid input"})
}
_, err = tx.Exec("INSERT INTO users ...", req.Name, req.Email)
if err != nil {
tx.Rollback()
return c.Status(500).SendString("insert failed")
}
tx.Commit() // ✅ 成功才 commit
return c.Status(201).SendString("created")
}
容易被忽略的坑
-
Fiber默认不绑定请求上下文（context.Context）到 DB 操作，超时或取消信号不会自动中断正在执行的 SQL —— 一定要用db.QueryContext(c.Context(), ...)这类带Context的方法 - 使用连接池（如
pgxpool）时，BeginTx返回的是*pgx.Tx，它和 pool 是解耦的，别误以为pool.Exec会自动参与事务 - 如果你用了 GORM，它的
Session(&gorm.Session{NewDB: true})或Transaction()才是事务入口，不是中间件能插手的
回滚不是魔法，它永远发生在 DB 驱动层，由你亲手写的 Rollback() 触发。中间件只管拦人，不管擦屁股。
