Go服务端r.FormValue("username")返回空字符串的根本原因是*http.Request默认不解析表单，r.Form和r.PostForm初始为nil；仅当请求为POST/PUT/PATCH且Content-Type为application/x-www-form-urlencoded或multipart/form-data时，r.FormValue()才首次触发自动解析。
Go 服务端解析表单失败，90% 是因为没搞清 r.ParseForm() 的触发时机和适用边界 —— 不是所有 r.FormValue() 调用都“自动安全”，尤其在混合请求或文件上传场景下，静默返回空字符串是常态，不是 bug。
为什么 r.FormValue("username") 总是返回空字符串
根本原因：Go 的 *http.Request 默认不解析任何表单数据，r.Form 和 r.PostForm 初始均为 nil。即使你写了 r.FormValue("username")，它内部的“自动解析”也只在首次调用时触发，且有严格前提：
- 仅当请求是
POST、PUT或PATCH，且Content-Type为application/x-www-form-urlencoded或multipart/form-data时，r.FormValue()才会尝试调用r.ParseForm() - 如果请求是
GET，它只查r.URL.Query()，完全忽略 body（哪怕 body 里真塞了数据） - 如果请求是
POST但Content-Type: application/json，r.FormValue()完全无效，不会报错，只会返回空串 - 若你已在 handler 前（如中间件）调用过
r.ParseForm()，后续r.FormValue()直接复用结果；但如果中间件里只调用了r.ParseMultipartForm(32，而你又没显式调用 <code>r.ParseForm()，r.Form仍可能为空
r.ParseForm() 和 r.ParseMultipartForm() 必须怎么配对用
普通文本表单（无文件）直接用 r.ParseForm() 就够了；但只要 HTML 表单加了 enctype="multipart/form-data"，或客户端发了文件字段，就必须提前调用 r.ParseMultipartForm() —— 否则 r.ParseForm() 内部会用默认 32MB 限制去解析 multipart，超限就 panic，错误堆栈还不指向你的代码。
- 含文件上传：必须先调用
r.ParseMultipartForm(32 （32MB），再调用 <code>r.ParseForm()（可选，因前者已隐式触发） - 只读取非文件字段（如
r.PostFormValue("title")）：仍需r.ParseMultipartForm()，否则r.PostForm为空 - 只处理纯文本字段（
application/x-www-form-urlencoded）：只需r.ParseForm()，r.ParseMultipartForm()完全不用碰 - 注意：
r.ParseMultipartForm()的参数是内存上限（单位字节），不是文件大小上限；大文件会写入临时磁盘，但字段过多或单字段超限仍会失败
r.FormValue() vs r.PostFormValue() 到底该用哪个
二者语义差异明确，混用是常见坑点：
立即学习“go语言免费学习笔记（深入）”；
-
r.FormValue("id")：合并 URL 查询参数和 POST body 字段，按 “query 优先” 规则取值。适合搜索页（GET /search?q=go&page=2或POST /search提交相同字段） -
r.PostFormValue("token")：只从 POST body 取值，完全忽略 URL 参数。适合登录、注册等纯提交场景，避免攻击者通过 URL 注入参数覆盖 body 值 - 两者都返回
string（首个值），若需全部同名值（如多选 checkbox），必须用r.Form["hobby"]或r.PostForm["hobby"]，它们返回[]string -
r.PostFormValue()不会自动触发解析 —— 如果r.PostForm还是nil，它直接返回空串，不报错也不解析；r.FormValue()则会尝试触发
JSON 请求体和表单共存时怎么安全切换
一个接口既要支持浏览器表单提交（application/x-www-form-urlencoded），又要支持前端 fetch 或 curl 发 JSON（application/json），不能靠猜 Content-Type 后统一走 json.NewDecoder(r.Body).Decode() —— 那样表单请求会报 invalid character 'u' looking for beginning of value。
- 正确做法：根据
r.Header.Get("Content-Type")分支处理 - 如果是
application/json：用json.NewDecoder(r.Body).Decode(&req)，记得检查解码错误 - 如果是
application/x-www-form-urlencoded或multipart/form-data：走r.ParseForm()或r.ParseMultipartForm()，再用r.PostFormValue() - 关键细节：不要重复读
r.Body—— JSON 解析后r.Body已关闭，不能再调用r.ParseForm()；反之亦然。需要共存逻辑时，应先判断类型，再分支执行 - 更稳妥的方案：前端约定统一用 JSON，浏览器表单改用
fetch+FormData+Content-Type: application/json（需手动序列化），服务端只处理 JSON
最易被忽略的一点：无论用哪种方式，r.ParseForm() 或 r.ParseMultipartForm() 的错误必须显式检查。Go 不会 panic，但返回 nil 的 r.Form 会让后续所有 FormValue 调用静默失效 —— 日志里看不到错误，只有空值。
