路径参数必须用c.Params()获取，如c.Params("id")，不可混用c.Query()；c.Query()仅取查询参数最后一个值，多值需c.Queries()；JSON用c.BodyParser()，表单用c.FormValue()，文件上传用c.MultipartForm()。
路径参数必须用 c.Params()，不能混用 c.Query()
路径参数（如 /user/:id 中的 id）和查询参数（如 ?page=2）在 Fiber 中完全隔离。误写成 c.Query("id") 永远返回空字符串，因为路径段根本不在 query string 里。正确做法是：路由定义时用冒号声明 → 处理器中调 c.Params("id") → 得到 string 类型值。
常见错误现象：c.Params("ID") 取不到值——命名大小写敏感，拼错就为空；请求 /user/123/（末尾多斜杠）不匹配 /user/:id 路由，需显式加通配符或重写路由。
注意：c.Params() 不做类型转换，哪怕 id 是数字，也得手动用 strconv.Atoi 解析；若想限制只接受数字，Fiber 不提供内建校验，必须自己用 regexp.MatchString 或 strconv.Atoi 判断并提前返回 400。
c.Queries() 和 c.QueryParser() 的适用边界
c.Query() 只取重复键的最后一个值（如 ?tag=a&tag=b 返回 "b"），真要支持多值，必须用 c.Queries()，它返回 map[string][]string，适合处理标签、筛选项等场景。
c.QueryParser() 仅支持扁平结构，遇到 user.name 这类点号嵌套会失败——这不是 bug，是设计限制。如果前端传的是 JSON 风格参数（如 ?filter={"name":"x"}），应先 c.Query("filter") 拿字符串，再 json.Unmarshal，别依赖 QueryParser。
分页参数必须手动校验：limit 建议硬性限制 ≤100，offset 必须检查是否为非负整数，否则 c.Query("offset") 返回空字符串，strconv.Atoi 会报错。
JSON 和 Form 数据要用 c.BodyParser() 或 c.FormValue()
POST/PUT 请求体中的 JSON 数据，用 c.BodyParser(&struct{}) 绑定，但注意：Fiber 不自动忽略私有字段或处理 time.Time 序列化，结构体字段必须加 json: tag，否则可能吐空对象或暴露敏感字段（如 PasswordHash）。
Form 表单数据（application/x-www-form-urlencoded 或 multipart/form-data）用 c.FormValue("field")；上传文件则必须用 c.MultipartForm()，不能用 FormValue 读取文件内容。
常见坑：BodyParser 不校验字段必填性，也不做类型范围检查（比如年龄不能为负）。需要额外逻辑判断，例如解析后检查 user.Age 就返回 400 错误。
Fiber v3 的自定义约束（RegisterCustomConstraint）不是银弹
Fiber v3 支持通过 app.RegisterCustomConstraint 定义路由参数校验规则（如 :id 必须是 6 位数字），但它只作用于路由匹配阶段——匹配失败直接 404，无法返回带语义的错误信息（如 “id must be numeric”）。
真正可控的校验仍得落在 handler 里：先让路由匹配成功，再用 c.Params() 取值 + 手动验证 + 返回 400 并附具体错误字段。v3 的约束更适合做快速过滤（比如拒绝明显非法路径），而不是替代业务层校验。
另外，RegisterCustomConstraint 不支持正则捕获组、不支持跨参数联动（如 “start_time 必须早于 end_time”），这类逻辑只能手写。
