omitempty 跳过字段的条件是：字段为类型零值且带有 json:",omitempty" tag；零值由类型定义（如 string 为 ""、int 为 0、*string 为 nil），非业务空值。
omitempty 是怎么跳过字段的，不是看值是否为空字符串或零值？
omitempty 的行为常被误解为“跳过空字符串、0、nil”，其实它跳过的是「零值（zero value）」且该字段有 JSON tag 声明了 omitempty。关键点在于：零值由类型决定，不是业务意义上的“空”。
-
string类型的零值是""，所以""会被跳过 -
int类型的零值是0，所以0会被跳过 —— 即使你本意是想存年龄 0 岁 -
*string的零值是nil，nil被跳过；但*string指向一个空字符串""，就不会跳过（因为指针非 nil） -
struct{}类型的零值是struct{}{}，它也会被跳过 —— 容易引发嵌套结构意外丢失
所以别指望 omitempty 区分“用户没填”和“用户填了 0/空串”，它只认内存层面的零值。
想让 0 或 "" 也保留，但又不想写自定义 MarshalJSON，怎么办？
最轻量的解法是换用指针类型 + omitempty，靠指针的 nil 表达“未设置”，靠非-nil 表达“已设置（哪怕设的是 0 或 ""）”。这比全量实现 MarshalJSON 更可控、更少出错。
- 把
Age int改成Age *int，传入&ageVar才会出现在 JSON 中；nil则彻底不出现 - 把
Name string改成Name *string，同理 ——""只要不是 nil，就一定输出 - 注意：HTTP JSON 解析时，
json.Unmarshal对*T字段默认会分配新值，即使原始 JSON 没给该字段（变成非-nil 零值），所以建议搭配json.RawMessage或预校验避免误初始化
示例：
type User struct {
Name *string `json:"name,omitempty"`
Age *int `json:"age,omitempty"`
}传入 {Name: nil, Age: &zero}，输出 {"age":0}；传入 {Name: &emptyStr, Age: nil}，输出 {"name":""}。
为什么 struct 字段用了 omitempty 还是没被忽略？
常见原因是字段未导出（首字母小写），Go 的 json 包根本看不到它，自然不会应用 omitempty 规则 —— 这时候字段既不序列化，也不报错，静默消失。
立即学习“go语言免费学习笔记（深入）”；
- 检查字段名是否以大写字母开头（如
Name✅，name❌） - 确认 struct 本身是导出的（如
User✅，user❌），否则整个 struct 无法被外部包访问 - 如果字段是匿名嵌入 struct，且该 struct 无任何导出字段，外层
omitempty也无效 - 使用
json:",omitempty"（逗号开头）会覆盖默认字段名，但不会影响可见性；可见性才是前提
错误现象：json.Marshal 返回 {} 或缺少预期字段，先 fmt.Printf("%+v", v) 看反射结果，再查导出性。
omitempty 和空值语义冲突时，后端 API 怎么设计才不翻车？
API 设计阶段就要明确：哪些字段允许“不传即忽略”，哪些必须显式传 null 或特定值。Go 默认不支持 JSON null 映射到非指针类型，所以服务端若需区分“未提供”和“提供 null”，必须用 *T 或 sql.Null* 类型。
- 前端 PATCH 请求中，只传变更字段 —— 后端应使用
map[string]json.RawMessage做部分解析，再按 key 更新对应字段，避免全量反序列化覆盖 - 数据库字段允许 NULL 时，Go struct 字段建议统一用
sql.NullString等，它们自带Valid字段，能明确表达“有没有值”，比*string更贴近存储语义 - 不要在同一个字段上混用
omitempty和业务级空值判断（比如认为""= 删除），JSON 层和业务层的“空”含义必须拆开处理
最容易被忽略的一点：前端发来 {"name":null}，用 *string 接收时，json.Unmarshal 会把指针设为 nil，等效于没传 —— 但如果你本意是“清空名字”，这就错了。此时得用自定义 UnmarshalJSON 或中间层转换。
