先从一个典型场景说起：当你用 Go 从 Docker API 拉取容器的 NetworkSettings 信息时，面对的是一个深度嵌套、类型混杂的 JSON。字符串、整数、布尔值，甚至 null 全混在一起，如果直接用 map[string]map[string]string 去接，立刻会收到 json: cannot unmarshal object into Go value of type string 的错误。原因很简单——IPPrefixLen 是数字 16，string 类型接不住；HairpinMode 是布尔值，同样不兼容；SecondaryIPAddresses 是 null，更是直接冲突。
那么，怎么才能把这类堆栈混杂的 JSON 稳稳地接住，而且接得安全、接得优雅？不卖关子，直接说结论。
结构化优先：这才是正解所在
推荐方案很明确：为每一层嵌套对象定义强类型的结构体。类型安全、可维护性高、IDE 支持好，还能方便写单元测试。下面是经过验证的写法：
type Network struct { IPAMConfig interface{} `json:"IPAMConfig"` Links interface{} `json:"Links"` Aliases interface{} `json:"Aliases"` NetworkID string `json:"NetworkID"` EndpointID string `json:"EndpointID"` Gateway string `json:"Gateway"` IPAddress string `json:"IPAddress"` IPPrefixLen int `json:"IPPrefixLen"` IPv6Gateway string `json:"IPv6Gateway"` GlobalIPv6Address string `json:"GlobalIPv6Address"` GlobalIPv6PrefixLen int `json:"GlobalIPv6PrefixLen"` MacAddress string `json:"MacAddress"`}type NetworkSettings struct { Bridge string `json:"Bridge"` SandboxID string `json:"SandboxID"` HairpinMode bool `json:"HairpinMode"` SecondaryIPAddresses *interface{} `json:"SecondaryIPAddresses"` SecondaryIPv6Addresses *interface{} `json:"SecondaryIPv6Addresses"` EndpointID string `json:"EndpointID"` Gateway string `json:"Gateway"` IPAddress string `json:"IPAddress"` IPPrefixLen int `json:"IPPrefixLen"` IPv6Gateway string `json:"IPv6Gateway"` MacAddress string `json:"MacAddress"` Networks map[string]Network `json:"Networks"`}这么做的好处非常明显：字段类型是明确的，零值语义清晰——int 默认 0，bool 默认 false，json tag 控制映射，而对于可能为 null 的字段，用 *interface{} 或 json.RawMessage 来安全接收。一句话总结：结构化建模是最稳妥的长期选择。
备选方案：动态类型兜底（仅限 Schema 不稳定场景）
当然，现实并不总是理想。有时候嵌套结构高度不确定，键名不可预知，字段类型变来变去。这时可以退一步用 map[string]interface{}，但代价是必须主动处理类型断言与错误：
type NetworkSettings struct { Networks map[string]map[string]interface{} `json:"Networks"`}// 使用时必须显式类型检查：for netName, netData := range settings.Networks { if ipPrefix, ok := netData["IPPrefixLen"].(float64); ok { settings.Networks[netName]["IPPrefixLen"] = int(ipPrefix) }}但必须提醒一句：这条路有代价。interface{} 丢掉了编译期类型检查，运行时 panic 的风险直线上升。比如 JSON 数字默认解包为 float64，转成 int 前必须校验是否为整数（math.Floor(ipPrefix) == ipPrefix），而 null 字段被解为 nil，访问前绝对要判空。这些细节稍不留神就会埋坑。
几个关键细节与最佳实践
- 字段导出规则：参与 JSON 编解码的结构体字段，首字母必须大写，否则
json包根本无法访问； - null 值处理：对可能为 null 的字段，推荐使用
*T（如*string）或json.RawMessage，避免解包失败； - 性能考量：结构体解析比
map[string]interface{}快 3 到 5 倍（实测），内存占用也更低； - 调试技巧：启用
json.Unmarshal错误检查，结合errors.As精准定位问题字段：
err := json.Unmarshal(data, &settings)if err != nil { var syntaxErr *json.SyntaxError if errors.As(err, &syntaxErr) { log.Printf("JSON syntax error at byte offset %d", syntaxErr.Offset) }}写在最后
面对复杂嵌套 JSON，原则其实很简单：永远优先选择结构化建模。为每一层嵌套对象定义对应的 struct，用 json tag 显式控制字段映射与行为。map[string]interface{} 只应作为临时适配或原型开发的补充手段。类型安全不是负担，而是 Go 在分布式系统中保障数据一致性的核心优势——从 NetworkSettings 到生产级 API 客户端，这一原则始终成立。
