r.ParseForm() 必须在读取 r.Body 之前调用，因为其解析依赖未耗尽的请求体流；一旦 r.Body 被读取，后续 ParseForm() 将失败且 r.Form 为空。
为什么 r.ParseForm() 必须在读取 r.Body 之前调用
Go 的 http.Request 对表单数据的解析是惰性的，且有一次性约束：一旦你手动读取了 r.Body（比如用 io.ReadAll(r.Body)），r.Form 和 r.PostForm 就会变为空，后续再调用 r.ParseForm() 也拿不到值。
这是因为底层把 Body 当作流处理，读完就 EOF；而 ParseForm() 内部会尝试重新读取 Body 来解析表单，但此时已不可用。
- 正确顺序：
r.ParseForm()→ 再取r.FormValue("key")或r.PostForm - 错误做法：先
io.ReadAll(r.Body)→ 再r.ParseForm()→ 结果r.Form为空 - 如果确实需要原始 body（比如做签名验证或透传），可用
r.ParseMultipartForm()配合r.MultipartReader()，或提前用bytes.Buffer缓存
r.FormValue() 和 r.PostFormValue() 的区别在哪
r.FormValue("name") 会自动合并 URL 查询参数（?name=alice）和 POST 表单数据（application/x-www-form-urlencoded 或 multipart/form-data 中的字段），按 “POST 覆盖 GET” 规则返回第一个非空值。
r.PostFormValue("name") 只查 POST 部分，不看 URL 参数，更严格也更安全——尤其在 API 场景中避免 GET 参数被意外覆盖。
立即学习“go语言免费学习笔记（深入）”；
- GET 请求带
?id=123，没 body →r.FormValue("id")返回"123"，r.PostFormValue("id")返回空字符串 - POST 请求 body 含
id=456，URL 也有?id=123→r.FormValue("id")返回"456"，r.PostFormValue("id")也是"456" - 若需明确区分来源（如审计日志），优先用
r.URL.Query().Get("id")和r.PostFormValue("id")
上传文件时为什么 r.ParseMultipartForm() 要设内存阈值
Go 默认只把小文件（32 字节，即 32MB）留在内存里解析；超过的部分会写入临时磁盘文件。但这个阈值必须显式调用 r.ParseMultipartForm(maxMemory) 设置，否则遇到 multipart 请求会直接返回 http.ErrNotMultipart 错误。
注意：这个调用本身不触发解析，只是预设配置；真正解析发生在首次访问 r.MultipartForm 或 r.FormValue 等方法时。
- 常见写法：
r.ParseMultipartForm(32 放在 handler 开头 - 若设为
0，表示全部写磁盘（不推荐，影响性能） - 若忘记调用，
r.FormValue("file")可能返回空，且r.MultipartForm为 nil，容易误判为“没传字段” - 上传大文件时，建议配合
context.WithTimeout和流式处理（r.MultipartReader()），避免阻塞
如何安全地获取多个同名表单字段（如复选框）
HTML 中多个 提交后，对应一个 key 多个 value。Go 不会自动合并成 slice，必须显式调用 r.Form["tag"] 或 r.PostForm["tag"] 获取 []string。
r.FormValue("tag") 只返回第一个匹配值，对多选场景完全不可用。
- 正确方式：
tags := r.PostForm["tag"]→ 得到完整字符串切片 - 若字段可能不存在，先检查：
if vals, ok := r.PostForm["tag"]; ok { ... } - 注意：即使只有一个 checkbox 被选中，
r.PostForm["tag"]仍是长度为 1 的 slice，不是单个 string - 不要用
len(r.FormValue("tag")) > 0判断是否提交——它掩盖了多值语义
r.FormValue() 依赖自动合并，一边又手动解析 r.URL.Query()，结果在边界 case（如 GET+POST 同 key）下行为不一致。保持数据源明确，比追求代码短更重要。 
