Buffalo框架默认不支持JSON嵌套解析，context.Bind()仅处理扁平参数；需手动用json.Unmarshal绑定预定义嵌套结构体，并显式声明json tag，避免使用map[string]interface{}或依赖中间件自动展开。
Buffalo 框架默认不提供 JSON 嵌套解析能力
Buffalo 是基于 Go 的全栈 Web 框架，其 context.Bind() 和 context.Param() 仅支持扁平结构的表单或查询参数解析，对嵌套 JSON（如 {"user": {"name": "Alice", "profile": {"age": 25}}}）不会自动展开字段。直接绑定到结构体时，若结构体字段未显式声明嵌套层级，会静默忽略或报 json: cannot unmarshal object into Go struct field 错误。
必须用 Go 原生 json.Unmarshal 手动处理嵌套结构
Buffalo 的请求体（c.Request().Body）仍是标准 *http.Request，所以解析嵌套 JSON 的责任完全落在开发者手上。推荐做法是：先读取原始字节，再用 json.Unmarshal 绑定到预定义的嵌套结构体。
- 定义结构体时，嵌套字段需用导出（首字母大写）字段 + 匹配 JSON key 的
json:tag - 避免使用
map[string]interface{}——它虽能接任意嵌套，但后续取值要反复类型断言，易出 panic - 务必检查
json.Unmarshal返回的 error；Buffalo 不会帮你拦截这个错误
示例：
type Profile struct {
Age int `json:"age"`
}
type User struct {
Name string `json:"name"`
Profile Profile `json:"profile"`
}
func CreateUser(c buffalo.Context) error {
var u User
if err := json.NewDecoder(c.Request().Body).Decode(&u); err != nil {
return c.Error(400, err)
}
// 后续逻辑...
return c.Render(201, r.JSON(u))
}
别依赖 Buffalo 中间件自动解析嵌套字段
Buffalo 的 Bind 中间件（如 binding.Bind）底层调用的是 json.Unmarshal，但它只在你传入具体结构体类型时才生效；若传 interface{} 或没指定类型，它不会推断嵌套结构。常见误区是以为加了 binding.Bind(User{}) 就能自动解出 user.profile.age —— 实际上，它只解顶层字段，嵌套部分仍为 nil 或零值。
- 中间件无法替代明确的结构体定义
- 如果前端发的是数组包裹对象（如
[{"user": {...}}]），必须用切片类型接收，不能用单个结构体 -
c.Param("user.profile.age")在 Buffalo 中根本不存在——它只解析 URL 路径和查询参数，不解析请求体 JSON
复杂嵌套建议拆成独立 handler 或用 json.RawMessage 延迟解析
当 JSON 层级深、字段动态多（比如配置模板、DSL 描述），硬编码结构体维护成本高。这时可先用 json.RawMessage 把某段嵌套内容暂存为字节流，等真正需要时再二次解析。
-
json.RawMessage避免重复解码，也绕过初期结构体不匹配问题 - 注意：它不会做任何验证，错位的 JSON 可能在下游才暴露
- 不要在日志里直接打印
json.RawMessage值——它输出的是字节切片地址，不是可读 JSON
例如：
type ConfigRequest struct {
ID string `json:"id"`
Params json.RawMessage `json:"params"` // 暂不解析
}
// 后续按业务分支决定如何 decode params
实际项目中，最容易被忽略的是：Buffalo 的错误响应默认不包含原始 JSON 解析失败的具体字段位置。一旦嵌套结构稍有偏差，排查就得靠手动加 log 或用 json.Compact 格式化后比对——这点比 Gin 或 raw net/http 更不透明。 
