在 go 中将 json 解析为 `interface{}` 虽然灵活，但会牺牲类型安全、可读性与运行时性能；若需频繁访问字段或构建可靠业务逻辑，应优先使用结构体；仅在纯透传（如代理 api）场景下才考虑 `interface{}`。
在 Go 的 JSON 处理实践中，开发者常面临一个关键设计选择：是将 JSON 数据解码为强类型的嵌套结构体（struct），还是直接解码为 interface{}？表面上看，后者写法简洁、无需预定义 schema，尤其适用于结构动态或快速原型开发的场景。但深入分析后会发现，这种便利性背后隐藏着若干不可忽视的代价。
✅ 类型安全与可维护性受损
使用 interface{} 会导致所有字段访问都需手动类型断言，例如：
var data interface{}
json.Unmarshal(b, &data)
m := data.(map[string]interface{})
items := m["items"].([]interface{})
firstItem := items[0].(map[string]interface{})
images := firstItem["images"].([]interface{})
// ... 还需继续断言 images[0]、areas 等 —— 易错且无法编译期校验一旦 JSON 结构发生微小变更（如字段名拼写错误、数组变为空或 null），程序将在运行时 panic，而结构体则能通过编译检查 + json 标签绑定提供明确的错误提示和 IDE 自动补全支持。
⚡ 性能实测：结构体显著更优
Go 内置基准测试清晰表明，结构体解码比 interface{} 快约 1.7 倍：
BenchmarkInterface 300000 6208 ns/op BenchmarkStruct 500000 3622 ns/op
原因在于：json.Unmarshal 对 interface{} 需依赖 reflect 动态构建嵌套 map[string]interface{} 和 []interface{}，每次赋值都涉及类型推导与接口包装；而结构体路径在编译期已知，可直接内存拷贝并跳过反射开销。
? 何时可接受 interface{}？
仅推荐以下两种场景：
- JSON 透传（Proxy）：如网关服务接收请求后原样转发，不解析、不校验、不修改；
- Schema 完全未知的元数据处理：例如通用配置中心读取任意格式配置，后续交由插件动态解释。
即便如此，也建议搭配 json.RawMessage 延迟解析，兼顾灵活性与性能：
type Payload struct {
Metadata json.RawMessage `json:"metadata"`
Data json.RawMessage `json:"data"`
}
// 仅在真正需要时再 Unmarshal RawMessage → struct✅ 最佳实践建议
- 优先生成结构体：利用 json2struct 或 gojson 工具将典型 JSON 样本一键转为 Go struct；
- 为可选字段添加 omitempty 和零值处理；
- 结合 json.RawMessage 处理混合结构（如多态字段）；
- 单元测试覆盖边界情况（空数组、null 字段、类型不一致等）。
归根结底，Go 的哲学是“显式优于隐式”。用结构体解码不是妥协，而是对代码健壮性、协作效率与长期可维护性的主动投资。
