Go解析JSON时null被忽略或panic的解决方法：用*string等指针类型接收可空字段；对三态需求（null/空值/缺失）用NullString；避免interface{}和滥用json.RawMessage；优先用标准库，第三方库仅在性能或功能受限时引入。
Go 解析 JSON 时 null 被忽略或 panic 怎么办
Go 的 encoding/json 默认把 JSON 中的 null 当作“字段不存在”，如果结构体字段是非指针类型（比如 string、int），又没设默认值，反序列化会静默跳过——不是报错，而是留空或零值，容易埋坑。更糟的是，如果字段是 *string 但 JSON 给了 null，json.Unmarshal 会把指针设为 nil，这本身合法；但若误用未判空的解引用（如 *field），运行时 panic。
- 用指针类型接收可能为
null的字段：比如Name *string而非Name string - 对必填但允许
null的字段，考虑用自定义类型 +UnmarshalJSON方法控制逻辑 - 别依赖
omitempty判断是否为null：它只管零值，不管null；null进来后指针变nil，omitempty也生效，但语义不同 - 测试时务必覆盖
{"field": null}场景，不能只测{"field": "xxx"}和字段缺失
想区分 null、空字符串、字段缺失，该用什么类型
标准 string 或 *string 都不够：前者无法表示 null（变成空串），后者无法区分 null 和字段缺失（都是 nil）。真要三态分离，得自己造类型。
- 定义类似
type NullString struct { String string; Valid bool }，然后实现UnmarshalJSON：遇到null设Valid=false，字符串设Valid=true，字面量缺失则保持零值（Valid=false且String=""） -
database/sql.NullString可直接复用，它行为一致，但语义上偏数据库场景，用在纯 API 层也无妨 - 避免用
interface{}然后手动类型断言：虽然能拿到原始 token，但失去结构体绑定和类型安全，维护成本高 - 注意性能：每次解析都新建结构体 + 多一次判断，QPS 极高时可考虑缓存或预分配，但多数服务不需过早优化
json.RawMessage 能不能绕过 null 处理难题
可以，但只是延迟处理，不是解决。它把一段 JSON 字节原样存起来，不解析，等你后续按需展开。适合字段含义动态、或想统一做 null 检查的场景。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 声明字段为
Data json.RawMessage，反序列化后先检查len(Data) == 0或bytes.Equal(Data, []byte("null"))来判断是否为null - 后续再用
json.Unmarshal(Data, &target)解出具体结构，这时你已明确知道它不是null - 缺点明显：丢失编译期类型检查；嵌套深时代码分散；错误堆栈难定位到原始字段名
- 别滥用：如果 80% 字段都有稳定 schema，只为 1–2 个字段用
RawMessage，反而增加理解负担
第三方库如 gjson 或 jsoniter 值不值得换
除非你卡在性能或特定语法（比如路径查询、流式解析），否则没必要。标准库的 json 对 null 的处理逻辑清晰、文档全、兼容性稳。
立即学习“go语言免费学习笔记（深入）”；
-
jsoniter兼容标准库接口，替换成本低，对null行为一致，但多一个依赖；它优势在极致性能和部分扩展 tag，普通业务几乎感知不到差别 -
gjson是只读解析器，适合从大 JSON 中快速取几个字段，但它不走结构体映射，天然不涉及“字段类型怎么接null”的问题——你得自己写逻辑判断返回的Result是否IsNull() - 引入新库前先压测：标准库
Unmarshal在 1KB 以内 JSON 上通常 - 团队已有规范用标准库，突然切第三方，新人读代码要额外学一套行为约定，得不偿失
最常被忽略的一点：很多人只在反序列化时想 null，却忘了序列化时 nil 指针默认被忽略（因 omitempty 或零值跳过），导致 API 返回里“消失”了本应是 null 的字段。这时候得显式控制，比如用 json:",null" tag 或提前补 nil 值。
