Go 的 encoding/json 包天然支持可选字段：未提供的 JSON 字段不会覆盖结构体对应字段的初始值，因此只需定义结构体并直接解码即可；对需区分“未提供”与“零值有效”的场景，应使用指针类型字段。
go 的 `encoding/json` 包天然支持可选字段：未提供的 json 字段不会覆盖结构体对应字段的初始值，因此只需定义结构体并直接解码即可；对需区分“未提供”与“零值有效”的场景，应使用指针类型字段。
在构建 RESTful API 时，常需接收部分可选的 JSON 查询参数（如分页、排序、过滤字段）。Go 的标准库 encoding/json 对此有原生且简洁的支持——无需额外标记或特殊配置。
✅ 默认行为：零值即“未提供”
只要结构体字段已导出（首字母大写）并正确标注 json tag，json.Unmarshal 就会自动跳过缺失字段，仅更新 JSON 中存在的键。未出现的字段保持其 Go 零值：
type UserQuery struct {
Offset int64 `json:"offset"`
Limit int64 `json:"limit"`
SortBy string `json:"sortby"`
Asc bool `json:"asc"`
Username string `json:"username"`
First_Name string `json:"first_name"`
Last_Name string `json:"last_name"`
Status string `json:"status"`
}
// 示例：仅传 {"offset": 10}
var q UserQuery
err := json.Unmarshal([]byte(`{"offset": 10}`), &q)
if err != nil {
log.Fatal(err)
}
// q.Offset == 10, 其余字段均为零值：q.Limit == 0, q.SortBy == "", q.Asc == false 等
此时，可通过判断字段是否为零值来推断客户端是否显式设置了该参数（例如 q.SortBy != "" 表示用户指定了排序字段）。
⚠️ 注意：零值本身可能具有业务含义
若某个字段的零值（如空字符串 ""、0、false）在业务逻辑中是合法且有意义的（例如允许按空字符串排序，或状态 status="" 表示“全部”），则无法通过零值准确判断“字段未提供”还是“用户明确设为零值”。
此时，推荐使用指针类型：
-
*string、*int64、*bool等的零值为nil； - JSON 中缺失该字段 → 对应指针保持
nil； - JSON 中显式传
null或有效值 → 指针被赋值（&"value"或nil）。
type UserQuery struct {
Offset *int64 `json:"offset"`
Limit *int64 `json:"limit"`
SortBy *string `json:"sortby"`
Asc *bool `json:"asc"`
Username *string `json:"username"`
First_Name *string `json:"first_name"`
Last_Name *string `json:"last_name"`
Status *string `json:"status"`
}
// 解析后可精准判断：
if q.SortBy != nil {
fmt.Printf("Sort by: %s\n", *q.SortBy) // 显式提供了 sortby
} else {
fmt.Println("No sortby specified") // 字段未提供（或传了 null）
}
✅ 实际 API 处理建议
-
初始化结构体为零值（如
var q UserQuery），避免意外残留旧值； -
优先用指针处理语义敏感字段（如
Status、SortBy），确保“未提供”可被程序明确识别； -
对纯数值分页字段（Offset/Limit），若
0是合法默认值（如从头开始、不限制数量），可用普通类型；若需区分“未传”和“传了 0”，则改用*int64； - 配合 validator 库（如 go-playground/validator）做后续校验，但解码阶段无需强制要求字段存在。
总之，Go 的 JSON 解码机制设计简洁务实：不强制、不侵入、不魔改。合理利用零值语义与指针语义，即可灵活、安全地支撑任意组合的可选参数场景。
