在Golang后端开发中，JSON报文解析是最频繁的操作之一。很多接口由于历史原因或前端习惯，经常会出现可选字段、半截数据、嵌套动态结构等情况。如果结构体字段全用值类型，程序很难判断某个字段是客户端传了零值，还是压根没传。指针类型正好能补上这个缺口，让Unmarshal之后的结构体状态更诚实。
指针字段在Unmarshal中的底层行为
encoding/json包在解码时，会根据目标结构体字段的类型决定分配策略。当字段是string这类值类型时，若JSON里没有对应键，Go会把该字段保留为零值，也就是空字符串。当字段是*string时，解码器发现键不存在，就不动这个指针，它保持为nil；若键存在，解码器会新建一个字符串并让指针指向它。这种差异意味着我们可以用nil精确表达“客户端未提供”。
从源码角度看，json包在indirect函数中通过反射拿到字段地址，若是指针且当前为nil，只有在JSON中有值时才会调用new分配。因此指针字段天然具备“懒分配”特性。下面的例子展示了同一段JSON在值类型和指针类型下的不同解析结果：
package main
import (
"encoding/json"
"fmt"
)
type ValUser struct {
Name string
Age int
}
type PtrUser struct {
Name *string
Age *int
}
func main() {
data := []byte(`{"Name":"Tom"}`)
var v ValUser
json.Unmarshal(data, &v)
fmt.Printf("val: %+vn", v) // Age为0，无法区分未传还是传了0
var p PtrUser
json.Unmarshal(data, &p)
fmt.Printf("ptr: %+vn", p) // Age为nil，明确未传
}
上面代码里，ValUser的Age在打印时是0，业务层如果写if u.Age == 0就可能误以为用户填了0岁。而PtrUser的Age是nil，我们可以写if u.Age == nil来判断缺失，用*u.Age读取真实值。这种写法在开放API、配置中心同步等场景非常关键。
omitempty与指针的协作陷阱
很多开发者喜欢在结构体标签里写json:"age,omitempty"，希望空值不要输出。对于值类型，omitempty会在字段为零值时忽略。但对于指针类型，omitempty只在指针为nil时忽略，若指针指向一个零值（比如new(int)得到指向0的指针），它依然会被序列化出来。这个细节经常引发前端收到"age":0的困惑。
我们看一下对比示例。假设有一个更新用户资料的接口，只允许部分字段更新，后端用同一个结构体收数据再拼SQL。如果误用omitempty加值类型，零值就会覆盖数据库原有内容；改用指针后，只有非nil的字段才进更新列表，但务必注意指针指向零值的情况：
type UpdateReq struct {
Nickname *string `json:"nickname,omitempty"`
Score *int `json:"score,omitempty"`
}
func buildUpdateMap(r UpdateReq) map[string]interface{} {
m := map[string]interface{}{}
if r.Nickname != nil {
m["nickname"] = *r.Nickname
}
if r.Score != nil {
m["score"] = *r.Score
}
return m
}
在buildUpdateMap中，我们显式判断nil而非依赖omitempty，这样即便前端传了"score":0，由于指针非nil，业务逻辑也能正确把0更新进去，而不会像值类型那样分不清。反过来，若前端没传score，指针为nil，map里就没有score键，避免了误覆盖。这种“显式判空”比标签省略更可靠。
嵌套结构与多态报文中的指针技巧
真实业务里，JSON常常带嵌套对象，而且某些节点可能整段缺失。比如支付回调报文中，退款信息只在退款事件出现。把子结构定义成指针，就能用nil表达“这一整块都没来”。如果定义成值类型，子结构里的字段全为零，很难断定是没传还是传了全零块。
更进一步，当接口需要兼容多种报文形态时，可以用指针配合json.RawMessage做延迟解析。先定义顶层字段为*json.RawMessage，判断非nil后再根据类型字段Unmarshal到具体结构体。这样既省去提前全量解析的开销，也避免未知结构直接报错。
type Event struct {
Type string `json:"type"`
Data *json.RawMessage `json:"data"`
}
type OrderPaid struct {
OrderID string `json:"order_id"`
Amount int `json:"amount"`
}
func handle(b []byte) {
var e Event
json.Unmarshal(b, &e)
if e.Data == nil {
return
}
if e.Type == "paid" {
var op OrderPaid
json.Unmarshal(*e.Data, &op)
fmt.Println(op.OrderID)
}
}
上面代码把Data设为指针，若报文没有data键，e.Data就是nil，直接返回，不会触发后续解析。若来了数据，再按Type分支处理。这种手法在webhook、消息队列消费者里很常见，既清晰又安全。总的来说，Golang指针在JSON解析中不是炫技，而是补齐了“缺失语义”这块短板，用好了能大幅降低接口层的边界bug。