Go 的 json 包默认行为易踩坑：导出字段需显式 json tag 才能正确编解码；小写/下划线字段须用 json:”key” 映射；omitempty 会丢弃 false 和 0；动态结构宜用 json.RawMessage 延迟解析；类型不匹配时静默失败，需手动校验；高频场景应避免反射开销。
Go 的 json 包够用，但默认行为容易踩坑——比如字段名大小写不匹配、空值处理失控、嵌套结构解析失败。
struct 字段必须导出且带 json tag 才能编解码
Go 的 json.Marshal 和 json.Unmarshal 只处理导出（首字母大写）字段。没加 json tag 时，会按字段名原样映射；但实际 JSON 键名常是小写或下划线风格，不显式声明就对不上。
常见错误现象：json.Unmarshal 后字段仍是零值，json.Marshal 输出空对象 {}。
- 字段名小写（如
user_name）必须用json:"user_name" - 忽略字段加
json:"-"，设为可选加json:",omitempty" - 布尔/数字字段慎用
omitempty：false 和 0 会被直接丢弃，不是“未设置”
处理未知或动态 JSON 结构用 json.RawMessage 而非 map[string]interface{}
当部分字段结构不确定（比如 API 返回的 data 字段可能是对象、数组或字符串），map[string]interface{} 看似灵活，实则易引发 panic——类型断言失败、嵌套深了难取值、无法复用已有 struct。
更稳的做法是先用 json.RawMessage 延迟解析：
type Response struct {
Code int `json:"code"`
Data json.RawMessage `json:"data"` // 先存原始字节
}
后续按需解析：json.Unmarshal(data, &User{}) 或 json.Unmarshal(data, &[]string{})。
- 避免多次解析：一次
json.RawMessage+ 多次Unmarshal比反复转interface{}更快 - 不能直接在 struct 中嵌套
json.RawMessage字段做序列化输出，否则会输出原始 JSON 字符串而非内联结构
json.Unmarshal 遇到类型不匹配默认静默失败
比如 JSON 中 "age": "25"（字符串）试图解到 struct 的 Age int 字段，json.Unmarshal 不报错，只把 Age 设为 0 —— 这是 Go 的默认策略，但线上很难发现。
解决方法只有主动校验：
- 用
json.Decoder配合DisallowUnknownFields()捕获多余字段 - 对关键字段，在 Unmarshal 后检查是否仍为零值（如
if user.Age == 0 && !isAgeProvidedInJSON） - 更彻底：自定义
UnmarshalJSON方法，在里面做字符串转数字并返回 error
性能敏感场景慎用 json.Marshal / json.Unmarshal
标准库用反射，中小数据量没问题；但高频服务（如网关、日志上报）中，单次解析耗时可能达微秒级，累积起来明显。
可选替代方案：
- 用
easyjson或ffjson生成无反射的编解码函数（需提前生成代码） - 对固定结构，手写
MarshalJSON/UnmarshalJSON，跳过反射开销 -
encoding/json在 Go 1.20+ 对小结构有优化，但别指望它自动加速复杂嵌套
真正容易被忽略的是：哪怕只是多一层嵌套 struct，反射深度增加，性能下降可能翻倍——别只盯着数据体积看。
