结构体字段校验不能只靠 struct 标签，因 json/yaml 标签不参与校验，validate 标签缺乏上下文感知能力；应将校验逻辑抽离为接收结构体指针和上下文标识（如 "create"）的 Validate 方法，支持嵌套与切片显式校验，避免硬编码、伪复用及副作用。
结构体字段校验为什么不能只靠 struct 标签？
因为 json 或 yaml 标签只管序列化，不参与校验；而 validate 这类标签（如 github.com/go-playground/validator/v10）虽好，但默认行为常不够细粒度——比如无法区分“创建时必填”和“更新时可空”，也不能动态启用/禁用某字段校验。真实业务里，一个结构体可能被多个 API 复用，校验逻辑必须随上下文变化。
所以得把校验逻辑从结构体定义中抽出来，用函数或方法封装，而不是堆砌标签。
- 别在结构体里写
validate:"required,email"一用到底，先想清楚这个字段在哪种场景下才需要校验 - 避免把校验规则硬编码进 struct 定义，否则改个业务规则就得动模型定义
- 如果要用第三方 validator，至少用
StructPartial或自定义TagName配合上下文传参，而不是直接Validate.Struct()
怎么设计可复用的校验函数签名？
核心是让校验函数接收结构体指针 + 上下文标识（比如 "create" 或 "update"），而不是为每个接口写一个校验函数。这样同一个结构体，不同入口复用同一套逻辑，只是分支不同。
示例：
立即学习“go语言免费学习笔记（深入）”；
func (u *User) Validate(ctx string) error {
switch ctx {
case "create":
if u.Name == "" {
return errors.New("name is required on create")
}
if u.Email == "" || !isValidEmail(u.Email) {
return errors.New("email is invalid or missing")
}
case "update":
if u.Email != "" && !isValidEmail(u.Email) {
return errors.New("email is invalid")
}
}
return nil
}
- 不要用
interface{}+ 反射做通用校验器——类型丢失、错误信息难定位、性能差 - 校验函数名别叫
Check或Verify，统一用Validate，符合 Go 生态习惯 - 返回
error，而不是bool，方便链式调用和错误聚合
如何处理嵌套结构体和切片字段的校验？
嵌套结构体不是自动递归校验的。比如 User 包含 Profile *Profile，你得显式调用 u.Profile.Validate("create")，否则 Profile 字段为空也不会报错。
切片更麻烦：空切片合法？长度上限多少？每个元素是否都要校验？这些都得按业务明确。
- 对非空切片字段，先判
len(s) == 0，再遍历每个元素调用其Validate方法 - 嵌套指针字段（如
*Address）要先判!= nil，再校验，否则 panic - 避免在父结构体里写
for _, a := range u.Addresses { a.Validate(...) }这种重复逻辑，提取成ValidateSlice工具函数
为什么校验模块容易变成“伪复用”？
很多人把校验逻辑塞进一个 validator.go 文件，里面全是 func ValidateUserCreate(u *User) error 和 ValidateUserUpdate(u *User) error，看似复用，实则每加一个接口就要复制粘贴改函数名——根本没解耦。
真正可复用的关键在于：校验逻辑绑定在结构体上（receiver method），而不是散落在工具函数里；上下文参数驱动分支，而不是靠函数名区分场景；错误信息带字段路径（如 "profile.phone"），方便前端精准提示。
最容易被忽略的一点：校验函数不该修改原结构体字段（比如 trim 空格、转小写）。那是预处理，不是校验。校验只回答“合不合法”，不负责“修不修正”。这两步必须分离，否则测试难写、行为不可预测。
