c.bodyparser() 解析成功需结构体字段首字母大写且 json tag 与请求字段完全一致；可选字段建议用指针区分“未传”和“传空”；必须校验 content-type 头并传地址解析，否则静默失败。
c.BodyParser() 能解析成功，前提是结构体字段首字母大写且 json tag 与请求字段完全一致；否则永远是零值，不报错也不提示。
Json Schema Toolkit
下载
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
结构体字段必须导出且 tag 精确匹配
Fiber 底层用标准encoding/json，只处理导出字段（首字母大写）。
- 错误写法：type User struct { name string `json:"name"` } → name 小写，无法解析
- 正确写法：type User struct { Name string `json:"name"` }
- 若请求字段是 user_id，tag 必须写成 `json:"user_id"`，不能靠字段名自动推断
- 多余空格、下划线位置偏差、大小写不一致，都会导致字段静默丢失
可选字段要用指针或自定义类型
默认情况下，JSON 中缺失字段、传null、传空字符串，都变成零值，无法区分“没传”和“传了空”。
- 关键字段（如 ID、status）建议用 *string 或 *int
- var u User 解析后：u.Name == nil 表示未传，*u.Name == "" 表示传了空字符串
- 别全用指针——判空成本高，且易引发 panic；仅对业务语义上“必须区分是否传入”的字段加
Content-Type 和错误调试必须手动做
c.BodyParser() 只在请求头为 Content-Type: application/json 时生效，否则直接返回 fiber.ErrUnprocessableEntity。
- 前端漏设 header 是常见原因，后端不会自动 fallback
- 解析失败时，c.BodyParser() 返回的 error 往往不带具体 JSON 错误细节
- 调试建议：先用 c.Body() 拿原始字节，再用 json.Unmarshal()，检查错误类型
- 典型错误：json: cannot unmarshal string into Go struct field X.Y of type int → 前端传了 "123"，结构体却定义为 int别忽略中间件和响应覆盖问题
-c.BodyParser(&v) 必须传地址（&v），传值会导致静默失败（v 保持零值）
- 解析失败后若没 return，后续仍可能执行 c.JSON()，掩盖真实错误
- 生产环境禁用 fiber.Default()，它自带中间件可能干扰 body 读取或泄露日志
- 上线前务必用 Postman 发完整 JSON 样例，断点确认结构体字段是否真被赋值——文档读十遍不如看一眼变量值
最常被跳过的动作是验证 Content-Type 头和检查结构体字段是否导出。这两个点一错，整个解析链就静默失效，连 error 都不抛。
