Revel解析嵌套JSON必须手动读取请求体并流式解码，不可用c.Params；需定义匹配struct或用map[string]interface{}+json.RawMessage处理动态结构，并严格校验Content-Type、错误类型及字段tag。
Revel 中解析嵌套 JSON 不能靠 c.Params 或自动绑定
Revel 的 c.Params 只处理 URL 查询参数和表单值，对原始 JSON 请求体完全无感知；c.Params.JSON 也不存在。你若试图用 c.Params.Get("xxx") 去取嵌套字段，结果一定是空或 panic。必须手动读取并反序列化请求体。
必须用 json.NewDecoder(c.Request.Body) 流式解码
嵌套 JSON（比如 {"user":{"profile":{"name":"Alice","tags":["admin","dev"]}}}）要正确解析，核心是类型定义 + 流式解码：
- 先定义匹配结构的 Go struct（推荐），例如：
type Profile struct { Name string `json:"name"` Tags []string `json:"tags"` } type User struct { Profile Profile `json:"profile"` } type RequestPayload struct { User User `json:"user"` } - 在 Action 中用
json.NewDecoder(c.Request.Body)直接解码到该 struct 指针上 - 务必在解码后、返回前调用
defer c.Request.Body.Close()，否则连接复用时 Body 会被提前耗尽 - 不要用
ioutil.ReadAll或io.ReadAll先读全部字节再json.Unmarshal——这不仅多一次内存拷贝，还会导致后续中间件或日志无法读取 Body
遇到动态键名或不规则嵌套怎么办
当 JSON 结构不固定（如 key 是时间戳、ID 字符串，或同一字段有时是 object 有时是 string），别硬套 struct。改用 map[string]interface{} 或 json.RawMessage 延迟解析：
- 顶层用
map[string]interface{}接收，再按需下钻：userMap := data["user"].(map[string]interface{}) - 对可能变化的字段，声明为
json.RawMessage类型，等真正需要时再二次解码，避免早期 panic - 注意类型断言失败会 panic，务必加
ok判断：if tags, ok := userMap["tags"].([]interface{}); ok { ... } - 嵌套数组遍历时，Dart/JS 风格的
for (v := range arr)在 Go 里不适用——range返回的是索引，要取值得写arr[i].(map[string]interface{})
错误处理和 Content-Type 检查不能省
生产环境常见崩溃点不是语法错，而是没拦住非法输入：
- 开头检查
c.Request.Header.Get("Content-Type")是否包含"application/json"，否则直接 415 -
decoder.Decode()失败时，err可能是json.SyntaxError、json.UnmarshalTypeError等，统一返回 400 并带简明提示（如"Invalid JSON in 'user.profile.tags': expected array, got string"） - struct 字段未加
json:tag 会导致解码静默失败——字段保持零值，但程序不报错，排查极难 - 嵌套过深（如 >10 层）可能触发 Go 默认的 JSON 解析深度限制，需通过
decoder.DisallowUnknownFields()和自定义MaxDepth控制
嵌套越深，struct 定义和错误分支就越关键；靠 map[string]interface{} 走捷径，很快会在第三层类型断言时掉进 panic 坑里。
