Go null 写入指针字段后的 nil 判断

使用 Go 标准库 encoding/json 解码普通结构体时，JSON 的 null 会把对应指针字段设为 nil。应先处理 json.Unmarshal 的错误，再检查 cfg.Limit == nil，最后才读取 *cfg.Limit。字段缺失与显式 null 是两种输入，普通指针本身并不总能保留这一区别。

官方文档地址：https://pkg.go.dev/encoding/json#Unmarshal

把配置输入和修改权限分开

设想一个自动化任务接收额度配置：未提供 limit 可能表示沿用旧配置，null 可能表示撤销额度，0 则是一个实际整数。我会先把这三个含义写入接口约定，再决定 Go 字段类型；否则 nil 判断虽然没有 panic，更新动作仍可能做错。

本文讨论默认解码规则、导出的 *int 字段和 json:"limit" 标签。自定义解码方法、其他 JSON 库和 v2 选项需要按各自契约处理。能解析 null 只说明数据结构接受它，不代表调用者拥有清空配置的业务权限。认证、授权和发布通知仍应由外层服务负责。

解码成功后再判断字段指针

package main

import (
    "encoding/json"
    "fmt"
)

type Config struct {
    Limit *int `json:"limit"`
}

func main() {
    // 每个输入使用独立初值，避免上一个案例影响下一个。
    for _, input := range []string{`{}`, `{"limit":null}`, `{"limit":0}`} {
        old := 12
        cfg := Config{Limit: &old}
        if err := json.Unmarshal([]byte(input), &cfg); err != nil {
            fmt.Println("解码失败:", err)
            continue
        }
        // 先检查字段指针，再解引用；nil 不等于指向整数零。
        if cfg.Limit == nil {
            fmt.Printf("%s：字段为空\n", input)
        } else {
            fmt.Printf("%s：字段值=%d\n", input, *cfg.Limit)
        }
    }
}

这是供读者运行的独立示例，下面列的是按照默认规则推导的状态，并非本机实测记录。三个案例都从 Limit 指向 12 的独立对象开始。

nil 检查针对 cfg.Limit，不是 &cfg。把结构体地址传入 Unmarshal，是为了让它能够写回字段；检查这个地址并不能判断内部字段是否为空。null 也不会主动删除其他变量：若别处仍保存原先的整数指针，该引用依然存在。

完整快照使用新对象接收

如果任务每次收到的都是完整配置，我倾向于创建新的接收对象。新对象初始 Limit 就是 nil，因此缺失和 null 都落在“未配置”状态；这个合并必须是协议允许的。下面函数与前面的 Config 定义、json 和 fmt 导入配合使用。

// DecodeSnapshot 为完整快照创建独立对象，成功后再由调用方提交。
func DecodeSnapshot(data []byte) (Config, error) {
    var next Config
    if err := json.Unmarshal(data, &next); err != nil {
        return Config{}, fmt.Errorf("配置解码失败: %w", err)
    }
    // 此处按示例业务约束拒绝负数；nil 表示未配置额度。
    if next.Limit != nil && *next.Limit 

调用方只在返回错误为 nil 后保存 next。不要为了所谓复用而直接解码进正在使用的全局配置：缺失字段会保留旧值；类型错误也可能伴随部分字段修改。先做 next := current 也不等于深复制，因为指针字段仍可能与 current 指向同一块整数存储，非 null 输入可能修改旧对象。

这种新对象方式适合完整快照；若业务要求“缺失保持、null 清空”，就需要下面的补丁模型。

局部补丁显式记录字段是否出现

我会给补丁增加 Present 标志，值由原始成员是否存在决定。单看一个从零值开始解码的 *int，缺失和 null 都可能得到 nil；简单增加一层指针也不能自动获得可靠的三态协议。

package configpatch

import (
    "bytes"
    "encoding/json"
    "fmt"
)

type Config struct {
    Limit *int
}

type LimitPatch struct {
    Present bool
    Value   *int
}

func DecodeLimitPatch(data []byte) (LimitPatch, error) {
    // 本例是仅含 limit 的补丁协议；先保存成员原文及是否出现。
    var fields map[string]json.RawMessage
    if err := json.Unmarshal(data, &fields); err != nil {
        return LimitPatch{}, fmt.Errorf("补丁解码失败: %w", err)
    }
    // 顶层 null 不代表空对象，必须明确拒绝。
    if fields == nil {
        return LimitPatch{}, fmt.Errorf("补丁必须是 JSON 对象")
    }
    for key := range fields {
        if key != "limit" {
            return LimitPatch{}, fmt.Errorf("不支持的配置字段: %s", key)
        }
    }
    raw, present := fields["limit"]
    if !present {
        return LimitPatch{}, nil
    }
    if bytes.Equal(bytes.TrimSpace(raw), []byte("null")) {
        return LimitPatch{Present: true}, nil
    }
    // 只允许整数；字符串、对象和不适合 int 的数字均返回错误。
    var value int
    if err := json.Unmarshal(raw, &value); err != nil {
        return LimitPatch{}, fmt.Errorf("limit 必须为整数或 null: %w", err)
    }
    if value 

这里的触发输入仍是普通 JSON 对象。Present 为 false 时不更新；Present 为 true 且 Value 为 nil 时清空；Present 为 true 且 Value 非 nil 时使用整数值。DecodeLimitPatch 完成全部解析和额度约束后，外层才调用 ApplyLimitPatch 并提交配置。

示例主动拒绝顶层 null 和未知字段，但不提供重复键拒绝功能；如果协议禁止重复成员，需要额外设计输入策略。RawMessage 方案比直接声明一个指针字段多了代码，它的收益是将“用户没有修改”和“用户要求清空”明确保留下来。

错误时保留旧配置并返回原因

解码失败时不要继续读取候选配置并触发自动化任务。返回解析或额度约束错误，保留旧配置；成功后再提交新配置，并让外层记录哪个字段变更。日志无需输出整个请求体。对于共享配置，提交时还需要按程序已有的锁或不可变快照机制同步，示例函数本身不承担并发发布。

字段写了 omitempty，null 就会被忽略吗？不会。omitempty 影响编码时是否输出字段，不是解码时跳过 null 的开关。

为什么 int 字段收到 null 仍保留旧值？默认 encoding/json 对这类非指针标量的 null 不改值，也不因此报错。若业务需要可空整数，应使用指针或显式状态模型。

外层指针也可能变成 nil 吗？可能。若变量 cfg 是配置指针，并将 &cfg 作为接收地址解码顶层 null，外层指针本身也可能被清空。需要区分整个配置为空和配置内部 Limit 为空。

我的选择是：完整快照用独立新对象，局部补丁显式携带字段存在性；两种方式都先处理错误，再判断目标指针，最后依据业务协议提交修改。

参考：Go encoding/json 解码规则。