用 net/http 手动校验表单最可控：先显式调用 r.ParseForm() 并检查错误，再逐字段校验；邮箱用 net/mail.ParseAddress 或正则；多字段推荐 validator 库配合指针类型与 omitempty；错误须结构化返回字段级信息，前后端 name 严格对齐。
用 net/http + 手动校验处理表单提交最可控
Go 标准库不内置表单验证框架，直接用 net/http 解析表单并手写校验逻辑，反而最清晰、无隐式行为。适合中小项目或需精细控制错误位置的场景。
关键点：别依赖第三方中间件自动绑定，先用 r.ParseForm() 拿到原始值，再逐字段校验。这样你能决定「空字符串算无效」还是「允许为空但长度不能超 20」这类细节。
-
r.FormValue("email")获取字段值，注意它会自动调用ParseForm，但不报错——如果解析失败（如超限），FormValue返回空字符串，容易掩盖问题 - 更稳妥的做法是显式调用
r.ParseForm()，检查返回 error：if err := r.ParseForm(); err != nil { http.Error(w, "表单解析失败", http.StatusBadRequest) return } - 校验邮箱建议用
net/mail.ParseAddress或正则^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$，别只查 @ 符号
用 validator 库做结构体绑定与声明式校验
当表单字段较多、且和后端结构体强对应时，go-playground/validator/v10 是主流选择。它把校验规则写在 struct tag 里，配合 ParseForm 或 JSON 绑定一起用。
注意：它默认不处理空字符串（""）为零值的问题。比如 Age int `validate:"required"`，若表单传 age=（空值），Age 会被设为 0，而 required 不会触发——因为 0 是有效 int 值。
立即学习“go语言免费学习笔记（深入）”；
- 解决方案：对数字/布尔字段，加
omitempty并改用指针类型：*int，或用required_if等条件规则 - 字符串字段要区分「空」和「未提交」，建议统一用
string类型 +required+min=1 - 错误收集建议用
err.(validator.ValidationErrors)类型断言，再遍历获取字段名和失败规则：if errs, ok := err.(validator.ValidationErrors); ok { for _, e := range errs { log.Printf("字段 %s 失败规则: %s", e.Field(), e.Tag()) } }
前端错误提示要和服务端字段名严格对齐
服务端返回的错误必须带明确字段标识（如 {"email": ["格式不正确"], "password": ["至少8位"]}），否则前端无法精准标红对应 input。别返回模糊的「参数错误」或拼接后的字符串。
常见翻车点：表单用了 name="user[email]" 这种嵌套命名，但后端没做路径解析，直接按字面 key 查，导致校验逻辑和字段名错位。
- HTML 表单中避免使用方括号嵌套：
name="email"而非name="user[email]"，除非你明确实现了嵌套解析逻辑 - 后端返回 JSON 错误时，key 必须和 HTML 的
name属性完全一致（包括大小写、下划线） - 若用 AJAX 提交，确保
Content-Type: application/x-www-form-urlencoded，否则ParseForm读不到值
不要在 http.HandlerFunc 里混写业务逻辑和校验
把校验单独抽成函数，返回 map[string][]string（字段 → 错误列表），能让 handler 更轻、易测、可复用。尤其当同一字段在多个接口都要校验时（如手机号格式），复用性立刻体现。
典型错误：在 handler 里写一堆 if len(email) == 0 { ... } else if !isValidEmail(email) { ... }，后续加新规则就得改所有地方。
- 推荐签名：
func ValidateSignup(r *http.Request) map[string][]string - 校验函数只负责「发现问题」，不负责
http.Error或重定向——那是 handler 的事 - 测试时可直接传入伪造的
url.Values，无需启动 HTTP 服务器
