需先调用 r.ParseForm() 或 r.ParseMultipartForm() 才能获取表单值，否则 r.FormValue 始终为空；GET 用 r.URL.Query().Get，POST 必 parse 后取值；验证须手写，检查存在性、非空性、格式合法性，并 trim 空格；重定向传错用 session 或加密 cookie，且需回填合法字段。
如何用 http.HandleFunc 接收表单数据
Go 的标准库不自动解析表单，必须显式调用 r.ParseForm() 或 r.ParseMultipartForm()，否则 r.FormValue("key") 总是空字符串。
常见错误是直接读 r.FormValue 却忘了 parse —— 这会导致所有字段都取不到值，且无报错。
- GET 表单：用
r.URL.Query().Get("name")更轻量，无需 parse - POST 表单（
application/x-www-form-urlencoded）：必须先r.ParseForm()，再用r.FormValue("email") - 含文件上传的 POST（
multipart/form-data）：必须用r.ParseMultipartForm(32 ，参数是最大内存缓存字节数，太小会触发磁盘临时文件，太大可能 OOM
ParseForm 失败时为什么没报错但数据为空
r.ParseForm() 内部忽略多数解析错误（比如 malformed body），只记录在 r.ParseError 字段里，而这个字段默认不暴露、也不 panic。你得主动检查：
if err := r.ParseForm(); err != nil {
http.Error(w, "invalid form", http.StatusBadRequest)
return
}
更隐蔽的问题是：如果前端发了 JSON 但 Content-Type 写成 application/x-www-form-urlencoded，ParseForm() 会静默失败（因为无法解析 JSON 字符串为键值对），此时 r.Form 为空 map。
立即学习“go语言免费学习笔记（深入）”；
- 务必校验
r.Header.Get("Content-Type")是否匹配预期类型 - 调试时可打印
r.Body前 200 字节（用io.LimitReader防止读爆）看原始请求体 - 不要依赖
len(r.Form) > 0判断提交成功 —— 它可能因 parse 失败而为空
手动验证表单字段的最小可靠模式
Go 没有内置验证器，别依赖 struct tag + 第三方库做“全自动”校验 —— 很多库对空字符串、零值、缺失字段的处理逻辑不一致，反而掩盖业务语义。
推荐手写验证函数，聚焦三个判断点：字段是否存在、是否非空、是否符合格式。
email := r.FormValue("email")
if email == "" {
// 缺失或空字符串
}
if !strings.Contains(email, "@") {
// 格式错误（这里只是示意，真实应使用 net/mail.ParseAddress）
}
- 用
strings.TrimSpace清理前后空格，否则 " a@b.c " 会通过空检查但实际无效 - 数字字段别直接
strconv.Atoi—— 先strings.TrimSpace，再检查是否全数字（或用strconv.ParseInt并判 err） - 密码确认字段必须在服务端比对，不能只靠前端 JS；比对前同样要 trim
重定向后如何传递验证错误信息
HTTP 是无状态的，http.Redirect 后原请求上下文丢失，不能靠局部变量传 error。常见错误是把错误塞进 query 参数（如 ?error=xxx），这既不安全（敏感信息泄露）又难维护（URL 长度限制、编码问题）。
正确做法是用临时 session 存储，例如基于内存的 map + 时间戳过期（仅开发/简单场景），或用 gorilla/sessions。
- 若坚持无外部依赖，可用
http.SetCookie存加密后的错误信息（需自己实现简单 AEAD，至少 base64+时间戳+HMAC） - 避免在重定向 URL 中拼接用户输入，防止 open redirect（检查
url.Parse的IsAbs()） - 渲染错误页时，从 cookie/session 取出后立即清除，防止重复显示
最易被忽略的是：表单重新渲染时，应保留用户已填的合法字段值（比如邮箱填对了，密码错了，重定向回来邮箱框不能清空）—— 这需要把原始 r.Form 数据也暂存并回填到模板。
