用 Validate 方法手动校验结构体字段最直接可控，不依赖第三方、无反射开销、逻辑清晰，适合规则简单或性能敏感场景；需统一方法签名、尽早返回带字段上下文的错误、避免副作用操作。
用 Validate 方法手动校验结构体字段
Go 标准库不提供内置结构体验证机制，最直接可控的方式是为结构体定义 Validate 方法。它不依赖第三方、无反射开销、逻辑清晰，适合字段规则简单或对性能敏感的场景。
常见错误是把校验逻辑写在构造函数里，导致无法复用；或者返回 error 但没区分具体失败字段，调试困难。
- 方法签名建议统一为
func (s *MyStruct) Validate() error，便于组合和测试 - 每个字段校验后应尽早返回带上下文的错误，例如：
return fmt.Errorf("name is required")，而非仅fmt.Errorf("invalid") - 避免在
Validate中做副作用操作（如修改字段值），它只负责“判断”，不负责“修正”
用 github.com/go-playground/validator/v10 声明式校验
这是 Go 生态最主流的结构体验证库，支持 tag 驱动、嵌套结构、自定义函数，适合中大型项目或需快速接入验证逻辑的场景。
容易踩的坑是忽略初始化配置，导致 time.Time 或指针字段校验失效；或误用 omitempty 导致空字符串被跳过校验。
- 必须调用
validator.New()获取实例，不能直接用包级默认变量（v10 起已移除） - 注册自定义验证器时，函数签名必须为
func(fl validator.FieldLevel) bool，且需显式调用v.RegisterValidation - 对指针字段（如
*string）使用required_if等条件规则时，要确保字段非 nil 才进入校验，否则 panic - 示例 tag：
type User struct { Name string `validate:"required,min=2,max=20"` }
在 HTTP handler 中集成验证并返回结构化错误
验证不是孤立步骤，而是请求处理链的一环。直接 panic 或裸 http.Error 会丢失字段粒度，前端难处理。
典型问题是把所有错误拼成一个字符串返回，导致前端无法高亮对应输入框；或未统一错误格式，让 API 契约不稳定。
- 推荐定义错误结构体，如
type ValidationError struct { Field string `json:"field"` Message string `json:"message"` } - 解析
validator.ValidationErrors时，用err.Translate(translator)提取字段名和本地化消息，别硬编码字符串匹配 - HTTP 状态码统一用
400 Bad Request，不要因字段不同而改用422（除非明确遵循 RFC 4918） - 不要在中间件里自动调用
Validate()并拦截——结构体类型各异，泛型支持有限，易出错
自定义验证函数如何安全访问嵌套字段和上下文
当需要跨字段校验（如 EndAt 必须晚于 StartAt）或依赖外部状态（如数据库唯一性），纯 tag 不够用，必须写函数。
最容易被忽略的是并发安全：自定义函数若引用全局 map 或缓存，未加锁会导致数据竞争；或误把 FieldLevel 的 Top() 当作当前结构体，实际它是根对象。
- 获取当前结构体实例请用
fl.Parent().Interface()，再类型断言，而非fl.Top() - 跨字段比较时，用
fl.Parent().FieldByName("StartAt")取值，注意处理reflect.Zero和空值 - 涉及 IO 的验证（如查 DB）不应放在
Validate方法内——它该是纯函数；应拆到 service 层，验证器只负责同步规则 - 若必须异步，返回
error占位，由上层决定是否延迟执行，别让验证器自己启 goroutine
结构体验证真正的复杂点不在语法，而在错误语义的表达精度和生命周期管理：字段级提示、国际化支持、与业务流程的解耦、以及何时该由验证器说“不”，何时该交给领域逻辑判断。
