Go解析JSON时null被忽略或panic的解决方法用*string等指针类型接收可空字段对三态需求null/空值/缺失用NullString避免interface{}和滥用json.RawMessage优先用标准库第三方库仅在性能或功能受限时引入。Go 解析 JSON 时 null 被忽略或 panic 怎么办Go 的 encoding/json 默认把 JSON 中的 null 当作“字段不存在”如果结构体字段是非指针类型比如 string、int又没设默认值反序列化会静默跳过——不是报错而是留空或零值容易埋坑。更糟的是如果字段是 *string 但 JSON 给了 nulljson.Unmarshal 会把指针设为 nil这本身合法但若误用未判空的解引用如 *field运行时 panic。用指针类型接收可能为 null 的字段比如 Name *string 而非 Name string对必填但允许 null 的字段考虑用自定义类型 UnmarshalJSON 方法控制逻辑别依赖 omitempty 判断是否为 null它只管零值不管 nullnull 进来后指针变 nilomitempty 也生效但语义不同测试时务必覆盖 {field: null} 场景不能只测 {field: xxx} 和字段缺失想区分 null、空字符串、字段缺失该用什么类型标准 string 或 *string 都不够前者无法表示 null变成空串后者无法区分 null 和字段缺失都是 nil。真要三态分离得自己造类型。定义类似 type NullString struct { String string; Valid bool }然后实现 UnmarshalJSON遇到 null 设 Validfalse字符串设 Validtrue字面量缺失则保持零值Validfalse 且 Stringdatabase/sql.NullString 可直接复用它行为一致但语义上偏数据库场景用在纯 API 层也无妨避免用 interface{} 然后手动类型断言虽然能拿到原始 token但失去结构体绑定和类型安全维护成本高注意性能每次解析都新建结构体 多一次判断QPS 极高时可考虑缓存或预分配但多数服务不需过早优化json.RawMessage 能不能绕过 null 处理难题可以但只是延迟处理不是解决。它把一段 JSON 字节原样存起来不解析等你后续按需展开。适合字段含义动态、或想统一做 null 检查的场景。声明字段为 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 的处理逻辑清晰、文档全、兼容性稳。 Vozo Vozo是一款强大的AI视频编辑工具可以帮助用户轻松重写、配音和编辑视频。