reflect 不该直接用于字段级验证，因其仅支持类型检查而不提供验证逻辑，易导致代码难维护、类型不安全、性能差；应通过反射提取标签约束，交由明确的验证函数处理。
为什么 reflect 不该直接用于字段级验证
Go 的 reflect 包能读取结构体字段名、类型、标签，但它本身不提供验证逻辑——它只是“看”，不“判”。直接基于 reflect.Value 写验证循环，容易写出难以维护、类型不安全、且性能差的代码。比如手动判断 string 长度、int 范围、是否为空，既重复又易漏边界（如 nil slice、零值时间）。真正该做的是：用反射提取约束信息，把校验交给明确的、可测试的函数。
如何从结构体标签提取验证规则并执行
标准做法是结合 reflect.StructTag 和自定义验证器。例如用 validate:"required,min=3,max=20" 标签，再通过 structTag.Get("validate") 解析。关键点在于：不要在反射循环里写 if-else 判断每种规则，而是把解析结果转成统一的 []Validator 切片，每个 Validator 实现 Validate(v interface{}) error 方法。
-
required检查reflect.Value.IsZero()，但要注意指针、接口、map/slice 的IsNil()判定优先于IsZero() -
min=5对string是长度，对int是数值下限，需按v.Kind()分支处理 - 避免对
time.Time直接调IsZero()—— 它返回true即使字段非空（因零值时间是 0001-01-01），应改用!v.Interface().(time.Time).After(time.Time{})
使用 validator 库时，反射做了什么
像 go-playground/validator/v10 这类主流库，底层仍是 reflect，但它把反射封装在初始化阶段：首次调用 Validate.Struct() 时，递归扫描结构体字段，缓存每个字段的验证器链（如 required → email → len=10），后续验证直接复用。这意味着：你写的结构体标签被反射一次，之后全是普通函数调用，没有运行时反射开销。
- 标签值支持嵌套，如
validate:"gte=1,lte=100,required"，库会自动拆解并顺序执行 - 自定义验证函数（如
isChinese）通过SetCustomTypeFunc注册，反射只负责识别类型并转发到你的函数，不参与逻辑 - 注意
omitempty和validate标签无关联——前者影响 JSON 序列化，后者才控制校验是否跳过
哪些字段类型会让反射验证出错
反射无法安全访问未导出字段（首字母小写），这是 Go 的根本限制。更隐蔽的问题是：嵌套结构体中含 interface{} 或 map[string]interface{} 时，reflect.Value.Interface() 可能 panic（如 map 为 nil 时取 Len()）。还有 func、unsafe.Pointer、chan 类型字段，reflect 能读取但无法合理验证，应显式忽略或报错。
立即学习“go语言免费学习笔记（深入）”；
- 对
interface{}字段，先用v.Kind() == reflect.Interface && !v.IsNil()判空，再用v.Elem()获取实际值 - 对
map，必须先v.IsValid() && v.Kind() == reflect.Map，再检查v.IsNil()，否则v.MapKeys()panic - 遇到
func或chan，建议直接跳过并记录警告——它们本就不该出现在数据验证场景中
最常被忽略的是：验证器是否处理了嵌套结构体的错误路径传播。比如外层结构体字段 A 是内嵌结构体 B，B 验证失败时，错误信息里的字段路径应该是 A.Name 而不是孤立的 Name。这需要反射过程中维护字段层级，而非只看当前一层。
