该用 reflect.value.iszero 而不是 == 零值，当处理运行时类型不确定的 interface{}、泛型参数或反射遍历结构体字段时，== 会编译失败或 panic；iszero 按类型规则判断逻辑零值，支持结构体、指针、切片等，并对未导出字段有效。
什么时候该用 reflect.Value.IsZero 而不是直接比较 == 零值
当你处理的是运行时才确定类型的接口值、泛型参数或结构体字段反射遍历时，== 会编译失败或 panic。比如想统一判断任意 interface{} 是否为“逻辑零值”，就不能写 v == 0 或 v == ""——类型都不确定，哪来的字面量？reflect.Value.IsZero 就是干这个的：它按类型规则返回是否为该类型的零值。
- 结构体：所有字段都是零值才返回
true（注意：嵌套结构体字段也递归判断） - 指针/切片/map/chan/func/interface：nil 才算零值
- 数组：所有元素为零值才返回
true - 注意：
IsZero对未导出字段（小写首字母）依然有效，但前提是能拿到它的reflect.Value（比如通过reflect.Value.Field(i)）
reflect.Value.IsZero 在解包 JSON 或表单时的实际用途
常见于 Web 框架里做“非空校验”或“字段更新过滤”。比如用户 PATCH 请求只传了 {"name": "Alice"}，后端想跳过未传的 age 字段（不覆盖数据库旧值），就得区分它是“没传”还是“传了 null/0”。这时候不能依赖 json.Unmarshal 后直接判 user.Age == 0，因为 0 可能是合法值，也可能是没传导致的零值。
- 正确做法：用
reflect.ValueOf(&user).Elem()获取结构体值，再对每个字段调用.Field(i).IsZero() - 陷阱：如果字段是指针类型（如
*int），IsZero判的是指针是否为 nil，不是它指向的值；而int类型字段IsZero判的是值是否为 0——同一语义下行为不一致 - JSON tag 里的
omitempty是编码时的行为，和运行时判断无关，别混用
为什么 IsZero 对自定义类型可能返回意外结果
它不看方法，只看底层表示。如果你定义了 type MyInt int，哪怕实现了 IsZero() bool 方法，reflect.Value.IsZero 也完全无视，仍按 int 的规则判断：值为 0 就返回 true。
- 自定义类型想控制零值逻辑，必须用指针接收者实现
IsZero() bool方法，然后手动调用——reflect.Value.IsZero不会帮你发现或调用它 - 空 struct（
struct{}）的IsZero恒为true，哪怕它有方法 - 带未导出字段的 struct，只要所有字段（包括未导出）都是零值，
IsZero仍返回true；但你无法用反射修改未导出字段，所以这种“全零”状态通常只能靠初始化达成
性能和安全边界：别在热路径反复反射判断
每次调用 reflect.Value.IsZero 都要走反射运行时，比原生比较慢一个数量级。更麻烦的是，它对不可寻址的 reflect.Value（比如从 map 取出的 value）会 panic，报错 reflect: call of reflect.Value.IsZero on zero Value。
立即学习“go语言免费学习笔记（深入）”；
- 先用
.IsValid()和.CanInterface()做前置检查，尤其是从map[interface{}]interface{}或interface{}断言后得到的值 - 高频场景（如日志中间件、序列化循环）尽量提前缓存判断逻辑，或者改用类型断言 + 分支处理，避免进反射
- 注意：
reflect.ValueOf(nil).IsZero()返回true，但reflect.ValueOf((*int)(nil)).Elem().IsZero()会 panic —— 因为Elem()在 nil 指针上调用非法
最常被忽略的一点：IsZero 的“零”是 Go 类型系统的零值，不是业务意义上的“空”。比如时间字段是 time.Time{}（1 年 1 月 1 日）也算零值，但业务上它可能代表一个有效默认时间。别让它替你做业务判断。
