当前位置：首页 > 文章列表 > Golang > Go问答 > Go JSON null 解码到指针和结构体有什么区别

Go JSON null 解码到指针和结构体有什么区别

来源：17golang原创 2026-10-14 22:38:57 0浏览收藏

接口联调时最容易误判的一类问题，是响应里出现了 null，Go 结构体却没有报错，甚至还保留着上一次的值。关键不在于 null “能不能解码”，而在于目标字段是指针还是普通值：指针字段会被清空为 nil，普通结构体字段通常保持原值。

官方地址：https://pkg.go.dev/encoding/json

如果字段需要表达“没有对象”，使用指针或其他可表达空值的类型；如果它是普通结构体字段，JSON null 解码时不会报错，也不会自动把已有值清零。字段缺失和显式 null 是否相同，要结合对象初始值一起判断。

先还原线上症状：null 到底改了什么

假设订单接口返回一个可选的收货地址。服务端可能返回三种 JSON：

字段缺失：调用方没有提供地址信息。
字段为 null：调用方明确表示地址被清空。
字段为对象：调用方提供了新的地址。

如果 Go 结构体把地址声明成普通值，前两种输入都可能让业务层看到一个看似完整的旧对象。这个现象常被误认为是 JSON 库丢字段，实际是目标类型没有“空对象”状态。

看指针字段的分配与清空规则

encoding/json 对指针有两个关键规则：输入不是 null 且目标指针为 nil 时，会分配一个新值；输入是 null 时，会把指针设置为 nil。因此 *Address 能把“有地址”和“明确为空”表达出来。

Go JSON null 解码到指针字段时的分配和清空状态关系图 — 图1：指针字段在 JSON 对象、null 和缺失字段之间的静态状态示意图，不是运行截图或执行证据。

但字段缺失不会自动把指针清空。如果复用同一个目标对象进行多次解码，缺失字段会保留原来的指针；只有显式 null 才会清空它。这正是补丁请求和全量替换请求必须区分的地方。

看普通结构体字段为什么像没收到数据

普通字段没有 nil 状态。官方规则是：JSON null 解码到接口、map、指针或 slice 时会设为 nil；解码到其他 Go 类型时不会改变原值，也不会产生错误。

例如 Address Address 无法区分“没有地址”和“地址对象的所有字段都是零值”。如果地址本身是业务上的可选对象，就应把字段改成 *Address，或者设计一个明确的三态载体，而不是依赖零值猜测。

Go JSON null 对指针字段和普通结构体字段影响不同的对比关系图 — 图2：指针字段与普通结构体字段接收 null 时的结果对比示意图，不是运行截图或执行证据。

用一组最小代码复现差异

下面的例子刻意先填充旧值，再分别解码缺失字段和显式 null。这样可以避免只看零值，误把两种请求当成同一种语义。

package main

import (
    "encoding/json"
    "fmt"
)

type Address struct {
    City string `json:"city"`
}

type Profile struct {
    Name       string  `json:"name"`
    HomePtr    *Address `json:"home_ptr"`
    HomeValue  Address `json:"home_value"`
}

func main() {
    // 先放入旧值，用来观察“字段缺失”和“显式 null”是否覆盖它。
    old := Profile{
        Name:      "旧用户",
        HomePtr:   &Address{City: "杭州"},
        HomeValue: Address{City: "杭州"},
    }

    missing := old
    if err := json.Unmarshal([]byte(`{"name":"新用户"}`), &missing); err != nil {
        // 输入错误必须返回给调用方，不能把半更新对象当成成功结果。
        panic(err)
    }

    explicitNull := old
    if err := json.Unmarshal([]byte(`{"home_ptr":null,"home_value":null}`), &explicitNull); err != nil {
        // 显式 null 仍是合法 JSON，错误通常来自语法或类型不匹配。
        panic(err)
    }

    fmt.Printf("缺失字段: ptrNil=%v ptrCity=%s valueCity=%s\n",
        missing.HomePtr == nil, missing.HomePtr.City, missing.HomeValue.City)
    fmt.Printf("显式 null: ptrNil=%v valueCity=%s\n",
        explicitNull.HomePtr == nil, explicitNull.HomeValue.City)
}

这个例子会得到这样的结论：字段缺失时，两个旧地址都保留；显式 null 时，HomePtr 变成 nil，HomeValue 仍然保留“杭州”。如果要访问指针字段，先判断是否为 nil，不要直接读取 missing.HomePtr.City。

把类型选择和防复发检查固化

可以把字段建模规则写进接口契约：

接口语义	推荐 Go 类型	判断方式
对象可以明确为空	`*T`	`nil` 表示 null 或未设置
对象永远存在	`T`	只关心对象内部字段
缺失、null、具体值三态都重要	自定义可选类型	额外保存是否出现及是否为空

对于更新接口，还要明确“字段缺失是否代表保持不变”。如果是补丁语义，普通字段的保留行为可能正好符合预期；如果是全量替换语义，就不能复用旧对象等待 Unmarshal 帮你清空，应该先创建零值对象，或者显式处理每个字段的出现状态。

type OptionalAddress struct {
    Value   Address
    Present bool
    IsNull  bool
}

func (v *OptionalAddress) UnmarshalJSON(data []byte) error {
    // 先记录字段确实出现，避免把缺失字段误判成 null。
    v.Present = true
    if string(data) == "null" {
        // null 只改变状态，不伪造一个空地址对象。
        v.IsNull = true
        v.Value = Address{}
        return nil
    }

    // 非 null 输入必须按对象解码，错误直接返回给上层。
    v.IsNull = false
    return json.Unmarshal(data, &v.Value)
}

在回归测试中至少覆盖：字段缺失、字段为 null、字段为对象、复用旧对象四个场景。若接口还允许 ""、空对象或默认地址，它们应作为独立的业务状态测试，而不是和 JSON null 混为一谈。

总结

排查 Go JSON null 问题时，先看目标字段的 Go 类型，再看解码前对象是否已有旧值。指针字段适合表达“对象不存在”，普通结构体字段接收 null 时则保持原值；字段缺失还会保留复用对象中的旧状态。把这三条规则写进 DTO 设计和回归测试，才能避免一次看似成功的解码把旧业务数据继续带下去。