应使用c.ShouldBindJSON(&data)绑定到map[string]interface{}，而非map[string]string或any；它支持嵌套结构，失败返回错误供自定义处理，而BindJSON会自动中止请求。
如何用 gin.Context.BindJSON 接收任意结构的 Map 数据
直接用 BindJSON 绑定到 map[string]interface{} 是最常用也最稳妥的方式。Gin 内部用 json.Unmarshal 解析，天然支持嵌套 map、slice、基本类型混合的非结构化 JSON。
常见错误是试图绑定到 map[string]string —— 一旦前端传了数字、布尔或嵌套对象，就会静默失败或 panic。
- 必须声明为
map[string]interface{}（不能是any或interface{}，否则BindJSON无法写入） - 调用前检查
c.ShouldBindJSON(&data) == nil，别只靠c.BindJSON（它会自动 abort，不适合需要自定义错误处理的场景） - 如果请求体为空或不是合法 JSON，
ShouldBindJSON返回非 nil 错误，data保持零值（空 map），不会 panic
var data map[string]interface{}
if err := c.ShouldBindJSON(&data); err != nil {
c.JSON(400, gin.H{"error": "invalid JSON"})
return
}
// data 现在可安全遍历或取 key
为什么不用 c.PostForm 或 c.GetPostForm 处理 Map 类型请求
这些方法只适用于 application/x-www-form-urlencoded，且只能解析扁平 key-value，不支持嵌套、数组或类型区分。例如 {"user":{"name":"a","age":25}} 用 PostForm 只能得到原始字符串，还得手动 json.Unmarshal —— 多此一举，还容易漏掉 content-type 校验。
-
c.PostForm("user")返回的是字符串"{"name":"a","age":25}"，不是 map - 若前端发的是 JSON 但 header 没设
Content-Type: application/json，BindJSON会直接报错，而PostForm会误读为表单，结果不可控 - 真正需要兼容表单+JSON 的接口，应先检查
c.GetHeader("Content-Type")，再分支处理
c.MustGet("key") 和中间件传参不解决原始 Map 解析问题
有人想在中间件里提前解析 JSON 到 context，然后用 c.MustGet("parsed_body") 拿出来 —— 这能工作，但没必要绕这么远，且增加内存拷贝和类型断言成本。
立即学习“go语言免费学习笔记（深入）”；
-
c.Set("body", data)后，在 handler 里data := c.MustGet("body").(map[string]interface{})，强制类型断言有 panic 风险 - Gin 的 context 是 request-scoped，但反复 set/get 不如直接 bind 一次来得清晰、低开销
- 唯一适合用
c.Set的场景是：多个 handler 共享同一份已校验/转换后的数据（比如 auth token 解析结果），而不是原始请求体
注意 map[string]interface{} 中数字类型的默认行为
Go 的 json.Unmarshal 默认把 JSON 数字解成 float64，哪怕前端传的是 "age": 25。这不是 Gin 的 bug，是 Go 标准库设计如此。
- 取值时别直接
int(data["age"].(float64))，要先判断是否为float64，再用int(math.Round(v.(float64)))避免精度丢失 - 如果业务强依赖整型，建议定义结构体 +
json.Number字段，或改用gjson/fastjson等库做无反射解析 - 嵌套 map 的 key 名称大小写、空格、特殊字符都原样保留，但要注意 Go map key 是区分大小写的，
data["ID"]和data["id"]是两个 key
非结构化数据的核心是“不预设 schema”，但这也意味着所有类型转换、边界校验、空值处理都得手动补全——没有银弹，只有更早暴露问题。
