JSON测试易漏边界问题，因默认忽略未导出字段、静默跳过类型不匹配、nil切片/映射行为不一致且不校验标签拼写；需覆盖零值与nil区分、嵌套round-trip、错误输入健壮性、标签副作用四类用例。
为什么 json.Marshal 和 json.Unmarshal 测试容易漏掉边界问题
因为 Go 的 encoding/json 默认忽略未导出字段、静默跳过类型不匹配、对 nil 切片/映射行为不一致，且不校验结构体标签拼写错误。你写的测试如果只覆盖“字段值正确”，很可能在真实场景中因空指针、零值覆盖、嵌套结构丢失而崩溃。
- 未导出字段（首字母小写）不会被序列化，但反序列化时也不会报错——它只是默默忽略
-
json:"name,omitempty"在字段为零值时完全不输出，但反序列化后该字段仍会被设为零值，可能掩盖业务逻辑误判 - 如果结构体字段类型是
*string但 JSON 给的是字符串字面量，json.Unmarshal会失败并返回json.UnmarshalTypeError，但很多测试没检查 error - 嵌套结构体中某一层字段名拼错（比如
json:"user_id"写成json:"uesr_id"），反序列化后对应字段保持 nil 或零值，无提示
必须覆盖的 4 类测试用例（含可直接复用的断言）
不要只测“能跑通”，要验证行为是否符合预期。以下用例基于标准 testing 包，无需额外依赖：
-
零值与 nil 的区分：定义字段为
*string或[]int，分别测试 JSON 中缺失字段、显式null、空数组[]的反序列化结果 -
嵌套结构的 round-trip 完整性：先
json.Marshal再json.Unmarshal，用reflect.DeepEqual比较原始值和还原值（注意：time.Time 等需单独处理） -
错误输入的健壮性：传入非法 JSON 字符串（如
"{key: 1}"缺少引号）、类型错位（数字字段传字符串）、字段超长等，确认返回非 nil error -
结构体标签的副作用：故意把
json:"id,string"加在非数字字段上，或给int字段加stringtag 后传入 JSON 字符串，验证是否按预期转换或报错
一个易忽略但关键的测试点：json.RawMessage 的延迟解析
当结构体中某字段类型为 json.RawMessage，它会原样保存 JSON 字节而不解析。这常用于兼容可变结构或避免重复解析，但测试时容易忘记验证它的字节内容是否与原始输入一致——尤其是经过多次 Marshal/Unmarshal 后可能被格式化或截断。
type Payload struct {
ID int
Data json.RawMessage `json:"data"`
}
raw := []byte(`{"ID":1,"data":{"x":1,"y":2}}`)
var p Payload
err := json.Unmarshal(raw, &p)
if err != nil {
t.Fatal(err)
}
// 必须比较字节，不能用 string(p.Data) == `{"x":1,"y":2}` —— 因为 marshal 可能重排键顺序
if !bytes.Equal(p.Data, []byte(`{"x":1,"y":2}`)) {
t.Error("RawMessage content changed")
}
如何验证自定义 MarshalJSON/UnmarshalJSON 方法是否生效
实现这两个方法后，标准 json.Marshal / json.Unmarshal 会自动调用它们，但测试时若只构造结构体再序列化，可能误以为逻辑正常，实际却因方法内部 panic 或返回错误字节而失效。
立即学习“go语言免费学习笔记（深入）”；
- 在
MarshalJSON中故意返回nil, errors.New("test")，确认外部调用得到非 nil error - 在
UnmarshalJSON中接收非法 JSON（如[]byte("invalid")），检查是否返回预期 error 类型 - 使用
json.Compact对比输出字节，避免空格/换行干扰判断；不要依赖fmt.Sprintf("%s", out)做字符串比较 - 如果方法中调用了
json.Marshal处理子字段，记得测试递归深度过大时是否会栈溢出（尤其在循环引用场景）
nil、空切片、json.RawMessage 字节一致性、自定义方法的 error 路径——这些地方不写具体断言就等于没测。 
