Go net/http 默认不校验表单，必须手动验证：先 ParseForm()，再对 r.PostForm 逐字段类型转换、空值检查和规则校验，或用 validator 结构体绑定验证。
Go 的 net/http 默认不校验表单，得自己动手
Go 标准库的 http.Request.ParseForm() 只负责把 application/x-www-form-urlencoded 或 multipart/form-data 解析成 r.Form（url.Values），不做任何类型转换、空值判断或规则校验。你拿到的全是字符串，哪怕前端传来 age=abc，r.FormValue("age") 也照单全收，返回 "abc" —— 后续转 int 时才会 panic 或静默失败。
所以验证不是“要不要做”，而是“必须在解析后、业务逻辑前做”。常见做法是：先用 r.ParseForm()，再对 r.PostForm 或 r.Form 逐字段检查。
- 别依赖
r.FormValue()直接进业务逻辑，它不报错也不过滤 - 注意
r.Form包含 URL 查询参数和表单体，如需严格区分，用r.PostForm（仅 POST/PUT 等有 body 的请求） -
ParseForm()在首次调用时才真正解析；多次调用无副作用，但别在中间混用r.Body读取，会冲突
手动验证：用 strconv + 条件判断最可控
没有框架时，靠标准库组合是最轻量、最透明的方式。核心是：把字符串转目标类型 + 判断范围/格式 + 收集错误。
例如验证一个注册表单：
立即学习“go语言免费学习笔记（深入）”；
// 假设已调用 r.ParseForm()
email := r.PostFormValue("email")
username := r.PostFormValue("username")
ageStr := r.PostFormValue("age")
var errs []string
if email == "" {
errs = append(errs, "email 不能为空")
} else if !strings.Contains(email, "@") {
errs = append(errs, "email 格式不合法")
}
if username == "" || len(username) < 3 || len(username) > 20 {
errs = append(errs, "用户名长度需为 3–20 个字符")
}
age, err := strconv.Atoi(ageStr)
if err != nil {
errs = append(errs, "年龄必须为整数")
} else if age < 1 || age > 120 {
errs = append(errs, "年龄应在 1–120 之间")
}
- 空字符串检查必须显式写，
""和" "是不同的，需要strings.TrimSpace()处理前后空格 -
strconv.Atoi对负数、前导零等敏感；如需宽松解析，考虑strconv.ParseInt(s, 10, 64)并检查err == nil -
邮箱正则或第三方库（如
mail.ParseAddress）比简单@判断更准，但多数内部系统用@+ 长度已够用
用 go-playground/validator 做结构体绑定验证
当表单字段多、嵌套深、复用性强时，把表单映射到 struct 再用 validator 校验更高效。它支持 tag 驱动（如 validate:"required,email"）、跨字段约束（eqfield）、自定义函数。
示例：
type SignupForm struct {
Email string `form:"email" validate:"required,email"`
Username string `form:"username" validate:"required,min=3,max=20"`
Age uint8 `form:"age" validate:"required,gt=0,lt=121"`
Password string `form:"password" validate:"required,min=8"`
}
func handleSignup(w http.ResponseWriter, r *http.Request) {
if err := r.ParseForm(); err != nil {
http.Error(w, "解析表单失败", http.StatusBadRequest)
return
}
var form SignupForm
if err := r.ParseForm(); err != nil {
http.Error(w, "解析失败", http.StatusBadRequest)
return
}
// 手动赋值（或用 r.FormValue + reflect，但简单场景直接赋）
form.Email = r.PostFormValue("email")
form.Username = r.PostFormValue("username")
form.Password = r.PostFormValue("password")
if age, _ := strconv.ParseUint(r.PostFormValue("age"), 10, 8); age > 0 {
form.Age = uint8(age)
}
validate := validator.New()
if err := validate.Struct(form); err != nil {
for _, e := range err.(validator.ValidationErrors) {
log.Printf("验证失败: %s -> %s", e.Field(), e.Tag())
}
http.Error(w, "表单验证失败", http.StatusBadRequest)
return
}
// ✅ 通过验证，继续处理
}
- 注意：
validator不自动从http.Request绑定字段，需手动赋值或借助mapstructure等库 - tag 中的
form:"xxx"仅作标识，validator本身不读取 HTTP 表单；它只校验 struct 字段值 - 数字类型推荐用
uint8/int而非string，避免后续反复转换；但要小心ParseUint失败时的默认值（如0）可能误过验证
清洗（sanitization）不能和验证混为一谈
验证是“这个值合不合规则”，清洗是“这个值安不安全”。比如用户输入 ，验证可能只关心它是否非空、长度是否达标；但入库或渲染前必须 HTML 转义或移除标签。
- 输出到 HTML 页面时，用
html.EscapeString()清洗，别依赖前端过滤 - 存入数据库前，若用
database/sql+ 参数化查询（强烈推荐），SQL 注入风险极低，无需额外清洗；但若拼 SQL 字符串，必须用sqlx.In或白名单替换 - 文件上传的
filename必须用path.Base()截取，防止路径遍历（如../../etc/passwd） - 不要在验证阶段做清洗（如自动 trim），除非业务明确要求“前后空格无效”；否则会丢失原始输入，影响审计或日志分析
表单验证真正的难点不在语法，而在边界——比如“手机号允许+86前缀吗？”“邮箱大小写敏感吗？”“空格算有效输入吗？”。这些必须和产品对齐，代码只是忠实执行规则。
