fiber必须显式调用c.bodyparser(&user)解析json请求体，因它不自动反序列化；c.body()仅返回原始字节，结构体字段需导出并带json tag，且必须传地址否则静默失败。
必须显式调用 c.BodyParser()，Fiber 不会自动反序列化请求体 —— 这是和 Express 或 Flask 最容易混淆的点。
为什么 c.Body() 拿不到结构化数据
c.Body() 返回的是原始 []byte，不是解析后的 Go 结构体。Fiber 默认不注册任何自动解析中间件，所有 JSON 解析都需手动触发。
- 常见错误：写
c.BodyParser(user)却没加&，导致传值而非传址，解析静默失败（user保持零值） - 更隐蔽的问题：如果请求头
Content-Type不是application/json，c.BodyParser()仍会尝试解析，但可能因编码或格式问题返回json.Unmarshal错误，而非 HTTP 400 - 注意：Fiber 不像 Flask 的
request.get_json()那样做 MIME 类型预检 —— 它只管解码字节流，不管请求头是否合理
正确使用 c.BodyParser() 的写法
推荐在 handler 开头就做解析，并立刻检查错误，避免后续逻辑基于未初始化的结构体运行。
- 结构体字段必须导出（首字母大写），且带
json:tag，例如Name string `json:"name"` - 务必传指针：
err := c.BodyParser(&user)，&user是必须的 - 错误处理不要只打印日志，应返回明确状态码：
if err != nil { return c.Status(400).JSON(map[string]string{"error": "invalid JSON"}) } - 如果想兼容空字段或可选字段，结构体字段类型可用指针（如
*string）或加omitemptytag
别和 c.Params()、c.Query() 混用
路径参数、查询参数、JSON body 是三套完全独立的数据源，底层读取位置和解析时机都不同。
-
c.Params("id")只从 URL 路径（如/users/123）取字符串，不会碰 body -
c.Query("format")只从 URL 查询串（如?format=json）取字符串，与 POST body 无关 - 三者可以同时存在并共存：比如
POST /api/v1/users/123?draft=true+ JSON body{"name":"alice"}，分别用c.Params("id")、c.Query("draft")、c.BodyParser(&u)获取 - 误用
c.Params()去取 JSON 字段，结果永远是空字符串 —— 它根本不会看请求体
调试时怎么确认 JSON 解析失败原因
最常被忽略的是请求头缺失或 body 已被提前读取 —— 这类问题不会报 panic，但会让 c.BodyParser() 返回奇怪的 json: cannot unmarshal 错误。
- 用
c.Get("Content-Type")打印确认是否为application/json；前端用fetch或axios时必须显式设置headers: {'Content-Type': 'application/json'} - curl 测试别漏
-H "Content-Type: application/json"，否则服务端收不到合法 JSON 请求 - 不要在同一个 handler 里多次调用
c.Body()或c.BodyParser()—— Fiber 的 body 流只能读一次，第二次会返回空字节 - 临时加一行
fmt.Printf("raw body: %s\n", c.Body())看原始内容，能快速区分是前端发错，还是后端解析逻辑有问题
真正麻烦的不是解析本身，而是错误发生时没有明确上下文 —— 比如字段类型不匹配、嵌套结构缺失、甚至前端用了单引号写 JSON，这些都不会触发 HTTP 400，只会让 c.BodyParser() 返回一个泛化的 json.UnmarshalError。建议在开发期配合 Postman 或 curl 验证请求格式，而不是依赖日志猜错因。
