验证逻辑必须剥离http handler，接收原始数据并返回结构化错误；应使用结构体标签+反射实现声明式验证，支持嵌套递归校验与字段级错误映射。
验证逻辑不该耦合在HTTP Handler里
表单验证一旦写进 http.HandlerFunc，就很难被单元测试覆盖，也难以复用于CLI或gRPC场景。真正可复用的模块必须剥离传输层细节——只接收原始数据（比如 map[string]string 或结构体），返回错误列表或 nil。
常见错误是直接在Handler里调用 r.FormValue("email") 然后立刻校验，这导致验证逻辑无法脱离HTTP上下文。正确做法是先统一提取数据，再交给独立验证函数处理。
- 把请求数据转成
map[string]string或定义专用输入结构体（如type SignupForm struct { Email string `validate:"required,email"` }） - 验证函数签名应为
func Validate(v interface{}) []string或更明确的func (f *SignupForm) Validate() []string - 避免在验证函数里访问
http.Request、context.Context或数据库
用结构体标签 + 反射实现声明式验证
Go原生不支持注解，但结构体标签（struct tags）配合反射可以模拟类似效果。主流方案如 go-playground/validator 就是这么做的，但自己实现轻量版只需几十行。
关键不是“要不要用第三方库”，而是理解它怎么工作：遍历结构体字段，读取 validate 标签，按逗号分隔规则逐条执行（如 "required,email,max=100"）。
-
required对应非空判断（字符串非空、数字非零值、切片非nil且len>0） -
email用net/mail.ParseAddress而不是正则——后者漏判或误判太多 -
max=100需区分类型：字符串看len(s)，整数直接比较，切片看len(slice) - 字段名映射到错误提示时，别硬编码
"Email"，用reflect.StructField.Name或自定义标签如json:"email" form:"邮箱"
错误信息必须带字段上下文，不能只返回“参数错误”
前端需要知道哪个字段出错、为什么错，否则用户反复提交却不知如何修正。纯字符串 slice（如 []string{"邮箱格式不正确"}）丢失了字段键名，无法绑定到UI控件。
推荐返回结构体或 map：map[string][]string{"email": {"邮箱格式不正确"}, "password": {"密码长度不能少于8位"}}。这样前端可直接用 errors["email"] 渲染提示。
- 不要用
fmt.Errorf("email: invalid format")—— 错误类型难解析，也不利于i18n - 字段名用原始结构体字段名（如
Email），或统一转成 kebab-case（email）便于前端消费 - 如果验证逻辑里调用了外部服务（如检查邮箱是否已注册），这类业务规则错误也要归入对应字段，而非丢进全局错误
嵌套结构和切片验证容易漏掉递归
当表单含地址、多联系人等嵌套数据时，仅校验顶层结构体会跳过子字段。例如 type OrderForm struct { User UserForm `validate:"required"` }，若没显式递归调用 User.Validate()，User.Name 的 required 校验就永远不会触发。
切片同理：Items []ItemForm `validate:"min=1"` 只能校验长度，但每个 ItemForm 内部字段仍需单独验证。
- 遇到嵌套结构体字段，检查其类型是否实现了
Validator接口或有Validate()方法，有则递归调用 - 遇到切片字段，先校验长度约束（
min/max），再遍历每个元素，对每个元素做完整验证 - 递归深度要设上限（如5层），防止恶意构造的嵌套JSON导致栈溢出或无限循环
验证模块最难的部分不是写规则，而是让错误位置精准、字段名一致、嵌套不遗漏——这些细节决定了它能不能真正在多个项目里复用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
