必须用c.BodyParser(&v)传结构体指针，字段首字母大写且json tag严格匹配请求字段（如json:"user_id"），否则解析为零值；c.Params()和c.Query()分别取路径与查询参数，不可混用。
直接用 c.BodyParser() 解析 JSON 请求体，用 c.Params() 和 c.Query() 分开取路径与查询参数——Fiber 不自动合并或猜测参数来源，必须手动指定解析方式。
怎么正确解析 JSON 请求体
Fiber 不会自动反序列化请求体，c.Body() 返回的是原始字节，不是结构体。必须显式调用 c.BodyParser() 或手动用 json.Unmarshal()。
-
c.BodyParser(&v)必须传结构体指针（带&），否则解析静默失败，v保持零值 - 错误类型是
error，不是 HTTP 状态码；需自己判断并返回c.Status(400).JSON(...) - 字段标签要写对，比如
json:"user_id"，否则字段映射为空 - 别依赖中间件自动做这事——Fiber 默认不注册任何 JSON 解析中间件
路径参数和查询参数为什么不能混用同一个方法
c.Params("id") 和 c.Query("page") 底层数据源完全不同：前者来自 URL 路径段（如 /users/123 中的 123），后者来自 query string（如 ?format=json）。它们不共享解析逻辑，也不能互相替代。
-
c.Params()只对路由定义里的:id、:slug这类占位符有效；/users/:id?from=web中的from必须用c.Query("from") - 两者都返回
string，转数字得自己调strconv.Atoi()或strconv.ParseInt() - 查默认值用
c.Query("page", "1")，但c.Params()没默认值机制，未匹配就是空字符串 - 别在 handler 开头就调
c.FormValue()——它会消费并清空原始 body，后续再调c.BodyParser()就读不到数据
XML 请求体怎么安全绑定到结构体
Fiber 默认不处理 text/xml 或 application/xml，c.Body() 对这类请求通常为空或乱码。必须绕过自动解析，直取原始字节再交给安全 XML 库。
- 用
c.Request().Body()拿*fasthttp.ByteBuffer，再调.Bytes()得[]byte；别用c.Body() - XML 声明里的编码（如
encoding="GBK"）c.Body()不识别，硬转 string 会乱码 - 有 UTF-8 BOM（
\xef\xbb\xbf）时，xml.Unmarshal()会 panic，得先bytes.TrimPrefix(raw, []byte("\xef\xbb\xbf")) - 必须用
github.com/defusedxml/xml替代标准库encoding/xml，否则存在 XXE 漏洞；微信、支付回调等外部 XML 推送尤其不能省
参数解析失败时状态码为什么没生效
c.Status(400) 是链式调用的一部分，不立即发送响应。如果后续代码又调了 c.JSON() 或 c.SendString()，前面的状态码会被覆盖。
- 典型错误：写了
c.Status(400).SendString("bad json")却没return，接着执行了c.JSON(...)→ 最终返回 200 - 正确做法：设完状态后立刻
return，或统一用c.Status(400).JSON(map[string]string{"error": "invalid json"}) -
c.Response().StatusCode()可用于调试，确认最终写入的是哪个状态码 - Middleware 里提前终止也要
return，否则next(c)仍会执行，可能造成重复响应
最易被忽略的是：XML 解析前不切 BOM、JSON 解析不传指针、参数取错方法（比如用 c.Query() 去取路径参数），这三类问题不会报编译错误，但运行时数据永远为空或错乱。
