如何更好地验证JSON反序列化到嵌套结构体的过程？

将JSON/YAML反序列化为Go结构体时，核心验证需求通常包含三点：

• JSON中存在必填字段
• 字段类型匹配（避免字符串强制转为整数这类隐式转换）
• 字段值合法（符合指定范围或枚举值）

嵌套结构体指结构体的某个字段为另一个结构体类型，示例代码如下：

type Example struct {
    Attr1 int        `json:"attr1"`
    Attr2 ExampleToo `json:"attr2"`
}

type ExampleToo struct {
    Attr3 int `json:"attr3"`
}

对应的合法JSON示例：

{"attr1": 5, "attr2": {"attr3": 0}}

现有验证方案的局限性 #

以下聚焦整数类型场景，分析常见方案的问题：

1. 自定义UnmarshalJSON方法 #

通过实现UnmarshalJSON可以处理字段存在性和值验证，但不支持嵌套结构体自动触发验证——如果ExampleToo实现了UnmarshalJSON，反序列化Example对象时该方法不会被调用。若要支持嵌套，需编写递归验证的UnmarshalJSON，实现复杂度极高，尤其当嵌套结构体被多处复用的场景。

2. 基于结构体的验证库（如go-playground/validator） #

这类库通过标签指定验证规则，但验证逻辑基于已完成反序列化的结构体，而非原始JSON。比如整数类型字段标记validation:"required"时，值为0（既是合法整数零值，又会被误判为字段缺失）会返回错误。

3. 指针字段方案 #

为所有字段使用指针类型，通过判断指针是否为nil来验证字段是否存在，但使用时每次都需要解引用，对于整数、字符串这类基础类型来说，这种写法并不符合Go的惯用风格。

4. 初步构想的“姐妹结构体”方案 #

创建一个所有字段为指针的“验证用结构体”，先反序列化到该结构体完成必填字段验证，验证通过后再反序列化到无指针的主结构体。这只是初步思路，仍有优化空间。

更优的混合验证方案 #

可以采用分层验证+JSON库协作的方式，兼顾灵活性和易用性：

1. 字段存在性验证：在顶层结构体的UnmarshalJSON中，先将原始JSON解析为map[string]json.RawMessage，遍历必填字段列表检查是否存在；
2. 嵌套结构体验证：对嵌套字段的RawMessage，手动调用嵌套结构体的UnmarshalJSON方法，确保嵌套层级的验证逻辑被触发；
3. 类型转换与值验证：交由JSON库（如标准库encoding/json或性能更优的第三方库）处理类型转换，同时在每个结构体的UnmarshalJSON中完成自身字段的值范围/枚举验证。

示例实现思路：

import (
    "encoding/json"
    "fmt"
)

func (e *Example) UnmarshalJSON(data []byte) error {
    // 解析为RawMessage字典，检查必填字段
    var rawMap map[string]json.RawMessage
    if err := json.Unmarshal(data, &rawMap); err != nil {
        return err
    }
    // 校验必填字段是否存在
    requiredFields := []string{"attr1", "attr2"}
    for _, field := range requiredFields {
        if _, exists := rawMap[field]; !exists {
            return fmt.Errorf("required field %s missing", field)
        }
    }
    // 反序列化基础字段（使用别名避免递归调用）
    type ExampleAlias Example
    var alias ExampleAlias
    if err := json.Unmarshal(data, &alias); err != nil {
        return err
    }
    // 验证attr1的值范围
    if alias.Attr1 < 0 || alias.Attr1 > 100 {
        return fmt.Errorf("attr1 must be between 0 and 100")
    }
    // 手动触发嵌套结构体的验证逻辑
    if err := json.Unmarshal(rawMap["attr2"], &alias.Attr2); err != nil {
        return err
    }
    *e = Example(alias)
    return nil
}

func (et *ExampleToo) UnmarshalJSON(data []byte) error {
    var rawMap map[string]json.RawMessage
    if err := json.Unmarshal(data, &rawMap); err != nil {
        return err
    }
    // 校验必填字段attr3
    if _, exists := rawMap["attr3"]; !exists {
        return fmt.Errorf("required field attr3 missing")
    }
    type ExampleTooAlias ExampleToo
    var alias ExampleTooAlias
    if err := json.Unmarshal(data, &alias); err != nil {
        return err
    }
    // 验证attr3的值范围
    if alias.Attr3 < 0 {
        return fmt.Errorf("attr3 cannot be negative")
    }
    *et = ExampleToo(alias)
    return nil
}

这种方案的优势：

• 确保嵌套结构体的验证逻辑被触发；
• 基于原始JSON检查字段存在性，避免零值误判；
• 交由JSON库处理类型转换，无需手动解析类型；
• 每个结构体的验证逻辑独立，便于复用。

另外，也可以结合第三方JSON库（如goccy/go-json），它支持自定义反序列化钩子，能更便捷地实现嵌套验证，同时提升性能。

内容的提问来源于stack exchange，提问作者mike_b