c.postform 拿不到 multipart 表单普通字段，因其依赖的 formcache 仅在 parsemultipartform 成功执行后填充；若未显式解析（如未调用 formfile、maxmultipartmemory 设置过小或请求超限），缓存为空，postform 始终返回空字符串。
c.PostForm 为什么拿不到 multipart 表单里的普通字段？
因为 c.PostForm 依赖 Gin 内部的 formCache，而这个缓存只在成功调用 ParseMultipartForm 后才填充。如果你没显式触发解析（比如没调用 c.FormFile、没设 MaxMultipartMemory，或请求超限失败），formCache 就是空的，c.PostForm("name") 必然返回空字符串——哪怕表单里只有文本字段、根本没传文件。
常见错误现象：c.PostForm("title") 始终为空，但用 c.MultipartForm() 却能拿到 Value["title"]；或者前端确认提交了字段，后端却收不到。
-
ParseMultipartForm失败时（如请求体超限、格式非法、磁盘不可写），Gin 直接跳过填充formCache，后续所有PostForm调用都失效 -
MaxMultipartMemory默认是 32MB，但若设得太小（比如 1MB），而表单含大量文本字段（如富文本内容），也可能触发解析失败 - 混用
c.PostForm和c.Request.MultipartForm会导致行为不一致：前者是缓存视图，后者是原始解析结果，二者不自动同步
如何可靠读取 multipart 表单中的普通字段？
最稳妥的方式不是靠 c.PostForm，而是统一走结构体绑定或主动解析 MultipartForm。
- 如果字段固定且不多，用
c.ShouldBind(&struct{})—— 它会主动触发完整解析，不受formCache状态影响，还能做类型转换和校验 - 如果需要动态读取或混合处理（比如先校验字段再决定是否保存文件），直接调用
c.MultipartForm()，从返回值的Value字段取值：form, _ := c.MultipartForm(); title := form.Value.Get("title") - 避免在 handler 开头就调用
c.PostForm，尤其当后面还要调用c.FormFile时——前者可能因缓存未填充而失败，后者又会触发解析但不更新已读缓存
ParseMultipartForm 的 limit 参数到底管什么？
r.ParseMultipartForm(32 中的 <code>32 （即 32MB）只限制「非文件部分」的内存缓冲上限，不是整个请求体大小限制。
这意味着：普通字段（如 title、description）内容超过该值，就会解析失败，导致 formCache 不填充；而文件内容仍会流式写入临时磁盘，不受此值约束。
- 如果你的表单含超长文本（比如 Markdown 正文、JSON 配置），即使没传文件，也得把
MaxMultipartMemory设得足够大 - 全局设置推荐：
r.MaxMultipartMemory = 64 （64MB），比默认值更宽松，覆盖多数含大文本字段的场景 - 不要误以为设了这个值就能限制上传总大小——真正控制总大小得靠业务层校验或反向代理（如 Nginx 的
client_max_body_size）
为什么有时 c.PostForm 能用，有时不能？
关键看「谁先触发了解析」以及「解析是否成功」。Gin 的 getFormCache 实现里会尝试调用 r.ParseMultipartForm(c.engine.MaxMultipartMemory)，但仅当该调用无错时才填充缓存。
- 如果先调用
c.MultipartForm()或c.FormFile()，它们内部会触发解析并填充formCache，之后c.PostForm就能用 - 如果先调用
c.PostForm，而此时formCache还没填充，它就直接返回空，且不会重试解析 - 一旦
ParseMultipartForm因任何原因失败（比如临时目录不可写、boundary 解析异常），formCache永远为空，c.PostForm在整个请求生命周期内都无效
实际开发中，别赌 c.PostForm 是否可用——要么用 ShouldBind，要么用 MultipartForm().Value，这两条路径才是确定性的。
