在Go语言里，JSON处理主要依赖标准库的encoding/json包。结构体字段的标签可以控制字段名称、omitempty等细节，但当字段类型变成指针时，编码和解码的默认行为会发生一些变化。这些变化往往隐藏在文档里，如果不刻意验证，很容易写出有隐藏bug的代码。下面我们直接从代码表现入手，分析指针字段在JSON序列化中的实际规则。

编码阶段：nil指针与非nil指针的区别

先看最直接的序列化场景。定义一个包含值类型字段和指针类型字段的结构体，分别观察json.Marshal的结果。

package main
import (
    "encoding/json"
    "fmt"
)
type User struct {
    Name  string  `json:"name"`
    Age   *int    `json:"age"`
    Email *string `json:"email"`
}
func main() {
    age := 30
    u := User{
        Name: "张三",
        Age:  &age,
        // Email留空，即nil指针
    }
    data, _ := json.Marshal(u)
    fmt.Println(string(data))
}

运行后会输出：{"name":"张三","age":30,"email":null}。可以看到，非nil的Age指针被解引用，序列化成了它指向的值30；而nil的Email指针则直接输出null，而不是省略该字段。这一点和值类型字段的零值表现不同：值类型字段即使是零值也会被输出（除非加了omitempty），但nil指针始终会出现在结果中，值为null。

如果给Age字段加上omitempty标签：`json:"age,omitempty"`，那么当Age为nil时会被省略，但当Age指向的int值为0时（非nil指针），字段依然会被输出。例如一个指向0的int指针，序列化结果是"age":0，而不是省略。这是指针和值类型在omitempty处理上的核心差异：omitempty判断的是字段本身是否为零值，对指针而言，nil才是零值，非nil指针哪怕指向零值也不算是空。

解码阶段：指针字段的内存分配与null处理

反序列化时，encoding/json对指针字段的处理会先检查目标字段是否为nil。如果JSON中对应字段的值是null，那么指针字段会被置为nil，不会分配新的内存。如果JSON值是一个有效的数值、字符串或对象，则会先为指针分配新的内存，然后将解码后的值写入该内存。

package main
import (
    "encoding/json"
    "fmt"
)
type Config struct {
    Timeout *int    `json:"timeout"`
    Label   *string `json:"label"`
}
func main() {
    data := []byte(`{"timeout":10,"label":null}`)
    var c Config
    _ = json.Unmarshal(data, &c)
    if c.Timeout != nil {
        fmt.Println("timeout:", *c.Timeout)
    } else {
        fmt.Println("timeout is nil")
    }
    if c.Label == nil {
        fmt.Println("label is nil")
    }
}

以上代码输出：timeout: 10 和 label is nil。这验证了null值不会触发内存分配，而有效数值会创建新的int变量并将10赋值进去。理解这个机制很关键，因为如果开发者期望null可以被解码为零值并继续使用指针，那就错了——此时指针是nil，直接解引用会引发panic。

还有一个常见场景：当结构体字段是嵌套结构体指针时，例如`*Address`，JSON对象会触发分配一个新的Address实例，然后递归解析内部字段；JSON null则不会分配。如果嵌套结构体指针是nil但JSON提供了对象，解码过程不会报错，会正常实例化。这种设计允许在初始化时保持字段为nil，只在需要时才有内存占用。

omitempty对指针解码的影响与常见陷阱

解码时，omitempty标签基本不起作用，它主要在编码时控制字段是否输出。但有一个容易误解的点：如果一个指针字段带有omitempty，并且JSON输入中该字段缺失（而不是null），那么该指针会保持解码前的状态，可能是nil，也可能是之前赋值的旧指针。这一点与值类型字段不同，值类型字段缺失时会被重置为零值。下面的例子演示了指针字段在两次反序列化时可能残留旧数据的情况。

package main
import (
    "encoding/json"
    "fmt"
)
type Item struct {
    ID    int     `json:"id"`
    Count *int    `json:"count,omitempty"`
    Name  *string `json:"name,omitempty"`
}
func main() {
    n := 5
    name := "first"
    item := Item{
        ID:    1,
        Count: &n,
        Name:  &name,
    }
    // 第二次解析缺少count和name字段
    data := []byte(`{"id":2}`)
    _ = json.Unmarshal(data, &item)
    fmt.Printf("id=%d, count=%v, name=%v\n", item.ID, item.Count, item.Name)
    if item.Count != nil {
        fmt.Println("count value:", *item.Count)
    }
    if item.Name != nil {
        fmt.Println("name value:", *item.Name)
    }
}

输出结果是id=2，count和name指针仍然指向旧值5和"first"。这是因为JSON对象中没有count和name字段，encoding/json不会修改目标指针的现有内容。如果希望缺失字段时清空指针，必须手动将指针设为nil或者在解码前重新初始化结构体。这个行为在文档中没有详细说明，但可以通过源码逻辑推断：解码器只处理输入中实际存在的键，对于缺失键会跳过对应字段的赋值操作。

另一个陷阱涉及自定义MarshalJSON方法。当指针字段指向的类型实现了Marshaler接口时，序列化会调用该类型的MarshalJSON方法，而不是默认的值展开。同样，如果指针本身为nil，则不会调用任何方法，直接输出null。这种差异在调试时可能造成迷惑，尤其是当方法内部对nil接收者做了特殊处理时。建议在自定义序列化逻辑中显式处理nil指针的情况，避免程序意外崩溃或输出不一致。

指针字段的性能与内存考量

虽然指针提供了区分“未设置”和“零值”的能力，但也会带来额外的堆分配和间接寻址开销。在大量小结构体的序列化场景中，频繁的指针解引用可能影响性能。例如一个包含多个指针字段的struct，每次Marshal都需要解引用每个非nil指针，而Unmarshal则需要为每个有效JSON字段分配内存并写入值。如果字段数量很多并且在热路径上，这种开销会累积。

对比实验显示，在相同数据量下，值类型字段的序列化速度通常快于指针字段，因为值直接复制，不需要额外的指针追踪。但这并不意味着要完全避免指针：当字段确实需要表示“缺失”状态（例如数据库中的NULL与0有区别）时，指针是更安全的选择。开发中可以根据实际业务需求平衡：对于高频序列化且字段大部分非空的场景，考虑使用值类型配合自定义零值判断；对于低频但需要严格区分null和零值的接口参数，使用指针字段更合适。理解这些底层行为后，才能设计出既正确又高效的Go数据结构。