fiber框架中post请求体类型决定取值方式：c.formvalue仅对application/x-www-form-urlencoded和multipart/form-data有效；json需用c.struct(&v)传地址解析；text/plain等类型须用c.body()读原始字节自行解码；c.params、c.query、c.formvalue来源不同，不可混用。
POST请求体类型决定取值方式
Fiber不会自动解析所有Content-Type，c.FormValue只对application/x-www-form-urlencoded和multipart/form-data有效；发JSON却用c.FormValue，结果永远是空字符串。常见错误就是前端发{"user":"a"}，后端写c.FormValue("user")，拿不到值还查半天。
必须按请求头匹配方法：
-
application/json：优先用c.Struct(&v)（v是结构体变量，传地址）；失败时err来自json.Unmarshal，不是HTTP状态码 -
application/x-www-form-urlencoded或含文件的multipart/form-data：用c.FormValue("key")或c.FormFile("file") -
text/plain、application/octet-stream等：只能靠c.Body()读原始字节，自己解码
c.Params、c.Query、c.FormValue别混用
三者来源完全不同：c.Params("id")只取路径里的/user/:id部分；c.Query("page")只取?page=2这种查询参数；c.FormValue("name")只从请求体里取表单字段。写成c.Params("name")去读POST body，肯定返回空。
典型误用场景：
- URL是
/api/v1/users/123?format=json，想取123得用c.Params("id")（前提是路由定义为/users/:id），不是c.Query("id") - 想取
format=json，必须用c.Query("format")，c.FormValue("format")无效 - 路径参数和查询参数可共存，互不影响，但不能跨区访问
handler必须显式return，且返回error类型
签名固定是func(*fiber.Ctx) error，漏掉return nil会导致响应卡住或返回空内容——Fiber靠这个返回值判断是否继续执行中间件链。更危险的是在if分支里写了c.Status(400).SendString()却不return，后面c.JSON()还会执行，造成重复写响应，客户端可能收两个body或直接报错。
正确写法要点：
- 每个分支结束前必须
return，哪怕只是return nil - 不要用
panic或log.Fatal，Fiber靠返回error触发统一错误处理 - 如果想返回错误响应，推荐
return c.Status(400).JSON(fiber.Map{"error": "xxx"})，它自动设状态码+Content-Type
中间件里取POST参数要小心生命周期
Fiber的fiber.Ctx对象是复用的，body数据只在当前请求生命周期内有效。如果在自定义中间件里调用了c.Body()或c.Struct()，后续handler再调一次，可能读到空或脏数据——因为body流已被消费过一次。
安全做法：
- 参数解析尽量放在handler里，而不是中间件中
- 真要在中间件里读body，必须用
c.Request().Body()配合fasthttp底层API，并手动重置body流（不推荐新手操作） - 鉴权类中间件如需检查token，应从
c.Get("Authorization")或c.Query("token")取，避开body
c.Struct()必须传结构体变量的地址、以及body只能读一次这两点。很多问题现场调试时看不出异常，上线压测才暴露。
