Go语言怎么处理JSON中的空值？omitempty与默认值设置-Golang-PHP中文网

不会自动消失——需字段值确为类型零值且无其他逻辑干扰；omitempty仅跳过零值序列化，不改变字段值或影响反序列化。

go语言怎么处理json中的空值？omitempty与默认值设置

Go结构体字段加`omitempty`后，零值字段真的会消失吗？

不会自动消失——前提是字段值确实是该类型的零值，且 JSON 编码时没被其他逻辑干扰。omitempty 只在字段值等于其类型的零值（如 0、""、nil）时跳过序列化，但它不改变字段本身的值，也不影响反序列化行为。

常见误判点：指针字段即使为 nil，也满足零值条件，会被忽略；但若指针非空却指向零值（比如 *int 指向 0），它仍会被编码——因为指针本身非 nil，不触发 omitempty。

omitempty 对 string 字段：空字符串 "" 被忽略；非空字符串（哪怕只含空格）都会出现
对 *int 字段：nil 被忽略；&0 会被编码为 0
对 map[string]interface{} 或 []string：空 map（nil）或 nil slice 被忽略；空但非 nil 的 map（make(map[string]interface{})）或 slice（[]string{}）仍会编码为 {} 或 []

反序列化时 JSON 空字段（`null`）怎么映射到 Go 字段？

默认情况下，JSON 中的 null 值只能成功赋给指针、接口、map、slice、函数或 channel 类型字段；赋给普通值类型（如 int、string、bool）会报错：json: cannot unmarshal null into Go value of type xxx。

所以想安全接收可能为 null 的字段，必须用指针：

type User struct {
    Name *string `json:"name"`
    Age  *int    `json:"age"`
}

这样，JSON 中 {"name": null, "age": 25} 会正确解出 Name == nil、Age == &25。如果后续需要默认值，得手动判断并赋值，json 包本身不提供“设默认值”的标签机制。

想让字段在 JSON 中缺省时填默认值，有哪些可行方式？

Go 标准库 encoding/json 不支持类似 default:"xxx" 的 tag，所以得靠代码层控制。最常用且可控的方式是实现自定义的 UnmarshalJSON 方法：

JSON Toolkit

JSON文件多功能工具。支持格式化、验证、压缩、键排序及点记法路径查询。零依赖。

下载

func (u *User) UnmarshalJSON(data []byte) error {
    type Alias User // 防止无限递归
    aux := &struct {
        Name *string `json:"name"`
        Age  *int    `json:"age"`
        *Alias
    }{
        Alias: (*Alias)(u),
    }
    if err := json.Unmarshal(data, &aux); err != nil {
        return err
    }
    if aux.Name == nil {
        u.Name = new(string)
        *u.Name = "anonymous"
    }
    if aux.Age == nil {
        u.Age = new(int)
        *u.Age = 18
    }
    return nil
}

注意点：

必须用嵌套 Alias 避免调用自身 UnmarshalJSON 导致死循环
不能直接对 u.Name 赋值字符串字面量（如 u.Name = "xxx"），因为它是 *string，需先 new(string) 再解引用赋值
如果字段类型是值类型（如 int），又想设默认值，建议直接改用指针类型，否则反序列化 null 会失败

用 `omitempty` 和指针配合时，容易踩哪些坑？

最典型的坑是：本意想“有值才传，没值就忽略”，结果因字段被初始化过（比如结构体字面量里写了 Name: new(string)），导致空字符串也被编码出去，破坏了 API 兼容性或引起下游校验失败。

另一个隐蔽问题是字段生命周期混淆：比如某个 *string 字段，在反序列化后被设为 nil 表示“未提供”，但业务逻辑中又不小心做了 if u.Name != nil && *u.Name != "" 判断——这没问题；但如果写成 if *u.Name == "" 且 u.Name 是 nil，就会 panic。