go 的 json.unmarshal 不 panic，所有错误均通过 error 返回；必须检查 err != nil，测试需覆盖非法 json、字段标签对齐、json.rawmessage 延迟解析及错误输入拦截。
Go 的 json.Unmarshal 本身不抛出可恢复的 panic，但测试时若结构体字段标签写错、类型不匹配或嵌套过深，会静默失败或返回 err != nil —— 所以关键不是“能不能测”，而是“怎么让错误暴露得早、定位得准”。
用 json.Unmarshal 解析时必须检查返回的 error
Go 的 JSON 解析不会自动 panic，所有异常都通过 error 返回。忽略它等于默认接受任意格式的输入，极易掩盖字段名拼写错误（如 "user_id" 写成 "userid"）或类型错配（int 字段传了 "123" 字符串）。
- 永远用
err != nil判断解析是否成功，不要只看结构体字段值是否非零 - 在测试中故意构造非法 JSON（如缺少引号、多逗号、类型错位），验证你的代码是否真能捕获并处理
- 对空字符串
""、null、缺失字段等边界输入，明确预期行为（是返回 error？还是设为零值？）
测试结构体字段标签是否与 JSON key 对齐
Go 结构体的 JSON 标签（json:"user_id,omitempty"）是解析的唯一依据，拼写/大小写/下划线规则错一点，字段就收不到值，且无编译期提示。
- 用
reflect检查结构体字段的Tag.Get("json")，确保每个导出字段都有显式标签（避免依赖默认小写转换） - 在单元测试里，把原始 JSON 字节切片直接传给
json.Unmarshal，再比对结构体字段值，而不是只测序列化（json.Marshal）路径 - 注意
omitempty在反序列化时无效——它只影响序列化；反序列化时即使 JSON 中字段缺失，也会被设为零值，不会跳过
用 json.RawMessage 延迟解析嵌套或动态字段
当 JSON 中有不确定结构的字段（如 webhook payload 中的 data），硬编码结构体容易因新增字段或类型变化导致解析失败。此时应先用 json.RawMessage 提取原始字节，再按需解析。
立即学习“go语言免费学习笔记（深入）”；
- 定义结构体时，对动态部分使用
json.RawMessage类型字段，避免提前解析失败 - 测试时分别构造合法和非法的嵌套 JSON，验证延迟解析逻辑能否正确区分并报错
- 注意
json.RawMessage不会自动去除空白或校验语法，后续调用json.Unmarshal时仍需检查 error
避免在测试中用 map[string]interface{} 替代结构体
虽然 map[string]interface{} 能绕过结构体定义直接解析任意 JSON，但它牺牲了类型安全、IDE 支持和字段语义，且在深层嵌套时类型断言极易出错（如 v["data"].(map[string]interface{})["id"].(float64)）。
- 单元测试中坚持用真实结构体，哪怕临时定义一个最小结构体，也比用 map 更易维护和 debug
- 如果 API 返回字段极不稳定，优先考虑用
json.RawMessage+ 单独解析函数，而非退化到 interface{} - 测试覆盖率工具（如
go test -cover）对 map 分支的覆盖难以追踪，而结构体字段访问可精确到行级
最常被忽略的一点：JSON 解析测试不仅要覆盖“正确输入”，更要验证“错误输入是否被拦截在第一层”。比如一个 UserID int 字段，传 "abc" 应该立刻返回 json: cannot unmarshal string into Go struct field UserID of type int，而不是让业务逻辑拿到 0 后继续执行——那才是最难排查的 bug。
