c.PostForm在multipart表单中返回空字符串，是因为其依赖的formCache仅在ParseMultipartForm成功执行后填充，而该操作不会自动触发；若未调用FormFile、MultipartForm或显式解析，或MaxMultipartMemory设置过小导致解析失败，缓存始终为空。
c.PostForm 在 multipart 表单中经常返回空字符串，不是你代码写错了，而是 Gin 的 formCache 没被触发填充——它只在成功调用 ParseMultipartForm 后才生效，而这个动作不会自动发生。
为什么 c.PostForm 拿不到 multipart 表单里的普通字段
Gin 的 c.PostForm 不是直接读请求体，而是查内部缓存 formCache。这个缓存只有在 r.ParseMultipartForm() 成功执行后才会填入键值对。但该方法不会自动调用，也不会在你只调用 c.PostForm 时懒加载。
- 没调用
c.Request.FormFile、c.MultipartForm或显式c.Request.ParseMultipartForm，缓存就一直是空的 -
MaxMultipartMemory设置太小（比如默认 32MB），而请求里有大文件或大量文本字段，会导致ParseMultipartForm失败，缓存跳过填充 - 即使表单里只有文本字段、根本没传文件，只要没触发解析，
c.PostForm("name")仍返回空字符串
用 c.ShouldBind 替代 c.PostForm 更可靠
对于结构化表单（尤其是含多个字段的注册/配置页），c.ShouldBind 是更健壮的选择。它会主动调用完整解析流程，不依赖缓存，也不挑 Content-Type —— 只要能识别为 form 数据（application/x-www-form-urlencoded 或 multipart/form-data）就处理。
- 定义 struct 时用
formtag 映射字段名：Username string `form:"username"` - 调用
c.ShouldBind(&u)，它会自动处理编码差异、空值、类型转换 - 比手动写一堆
c.PostForm更少出错，也避免字段漏读或类型误判 - 如果绑定失败，
ShouldBind返回 error，可统一做日志或返回 400
上传文件时必须手动清理临时资源
c.Request.FormFile 返回的是 multipart.File（底层是 io.ReadCloser），它背后绑定了一个临时磁盘文件句柄。不关，就会泄漏；不删，临时目录会越积越多。
- 必须
defer file.Close()，且不能放在if err != nil分支外层，否则错误路径下会跳过 - 保存前先调用
os.MkdirAll(filepath.Dir(dstPath), 0755)，否则os.Create遇到不存在的父目录直接 panic - 对
header.Filename做基础校验，比如拒绝含../的路径，防止目录遍历 - 用
io.Copy(dst, file)流式写入，别用ioutil.ReadAll把整个文件 load 进内存
MaxMultipartMemory 的数值到底管什么
gin.Engine.MaxMultipartMemory（默认 32 * 1024 * 1024）只限制「非文件字段」的内存缓冲上限，不是总请求大小限制。
- 表单里的文本字段（如
title=xxx&desc=yyy）会被读进内存，超限就报错 - 文件内容不受此值约束：它们会流式写入
os.TempDir()下的临时文件，哪怕设成 1KB，1GB 的文件照样能传（只要磁盘够） - 真正拦住超大请求的是 HTTP 底层：如果整个请求体超过
MaxMultipartMemory，http.Request在读 body 阶段就会 panic，抛出http: request body too large - 线上服务建议根据业务预估设高一点（比如 64MB），并配合 Nginx 的
client_max_body_size做双层防护
最常被忽略的一点：c.PostForm 和 c.Request.MultipartForm 是两套独立机制，前者查缓存，后者走原始解析。混用时别假设它们同步——比如先调 c.Request.FormFile 再读 c.PostForm，看似合理，但若中间有并发或中间件干扰，结果可能不一致。
