直接用 ctx.params 或 ctx.query 校验易出问题，因 fiber 缺乏类型转换与结构化校验能力，手动判断重复难维护，错误响应不统一、空值转数字 panic、规则无法复用；应改用结构体+validator 标签解耦校验逻辑。
为什么直接用 ctx.Params 或 ctx.Query 校验容易出问题
因为 Fiber 默认不提供参数类型转换和结构化校验能力，手动写 if len(name) == 0 || !isValidEmail(email) 这类逻辑既重复又难维护。更关键的是：错误响应格式不统一、缺失字段缺失时 panic（比如把空字符串转 int）、无法复用校验规则——这些都会在接口变多后迅速失控。
真正该做的，是让校验逻辑和路由处理解耦，并利用 Go 原生结构体标签驱动验证流程。
- 别在 handler 里写
if err != nil { ctx.Status(400).SendString("xxx") }—— 每个接口都复制一遍，错漏难追踪 - 避免用
strconv.Atoi(ctx.Params("id"))直接转换：参数不存在或非数字时会 panic，必须包defer/recover或层层if err != nil - 结构体字段没加
json:标签？c.BodyParser()可能静默失败，但实际字段值为零值，后续逻辑误判
用 go-playground/validator/v10 + 结构体绑定是最稳的方案
Fiber 自带 ctx.BodyParser()、ctx.QueryParser() 等方法，配合 validator 能自动完成类型转换 + 规则校验 + 错误聚合。核心是定义带验证标签的结构体，而不是拼接 if 判断链。
示例：接收查询参数并校验邮箱和分页
type ListUserQuery struct {
Email string `query:"email" validate:"required,email"`
Page int `query:"page" validate:"required,min=1"`
Size int `query:"size" validate:"required,min=1,max=100"`
}
func ListUser(c *fiber.Ctx) error {
var query ListUserQuery
if err := c.QueryParser(&query); err != nil {
return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": "invalid query params"})
}
if err := validator.New().Struct(&query); err != nil {
return c.Status(fiber.StatusBadRequest).JSON(fiber.Map{"error": err.Error()})
}
// ✅ 此时 query.Email 是合法邮箱，query.Page >= 1，无需再判断
return c.JSON(fiber.Map{"data": []any{}})
}
- 注意
query:标签名必须和 URL 参数名一致（如?email=a@b.com&page=2） -
validate:标签支持嵌套规则，比如"required,eq=active|eq=pending" - 若想统一返回格式，可封装一个
ParseAndValidate工具函数，内部调用QueryParser+validator.Struct
ctx.Params 和 ctx.ParamsInt 的坑与替代写法
很多人习惯用 ctx.Params("id") 拿路径参数，再手动转 int——这是最常触发 500 的地方。Fiber 的 ctx.ParamsInt("id") 看似方便，但它在参数不存在或非数字时直接 panic，且无法定制错误码。
- 正确做法：用结构体绑定路径参数，例如
GET /user/:id对应type UserParam { ID uint `param:"id" validate:"required,gt=0"` }，再用c.ParamsParser(¶m) - 如果坚持用原生方法，请始终检查返回的 error：
id, err := strconv.ParseUint(c.Params("id"), 10, 64); if err != nil { return c.Status(400).SendString("id must be number") } -
ctx.Params返回的是字符串，空路径段（如/user//posts）会导致""，直接转数字必然失败
自定义错误响应和国际化支持要点
validator 默认错误信息是英文且格式固定（如 "Key: 'ListUserQuery.Email' Error:Field validation for 'Email' failed on the 'email' tag"），前端很难解析。需要重写翻译器，或提取具体字段和错误类型。
- 用
ut.RegisterTranslation+registerValidation替换默认提示，例如把emailtag 映射为"邮箱格式不正确" - 更轻量的做法：遍历
err.(validator.ValidationErrors)，提取Field()和Tag()，组装成map[string]string{"email": "邮箱格式不正确", "page": "页码必须大于 0"} - 别在每个 handler 里做这个——抽成中间件，放在路由组最前面，所有带校验的路由自动生效
validator 的 Required 和 Exists 行为不同：前者检查字段是否为空值，后者检查结构体字段是否存在（对指针有用）。多数场景用 required 就够了，但接收可选更新数据时，得靠指针字段 + omitempty + 自定义校验逻辑来区分“未传”和“传了 null”。
