c.PostForm返回空字符串是因为Gin的form cache未被触发填充；需改用c.ShouldBindWith(&v, binding.FormMultipart)主动解析，并合理设置MaxMultipartMemory与字段max校验。
为什么超大纯文本字段在 Gin 里总是读不到
c.PostForm 返回空字符串，不是你漏写了 ParseForm，而是 Gin 的 form cache 根本没被触发填充。只要表单是 enctype="multipart/form-data"（哪怕一个文件都没传），Gin 就走 multipart 解析路径；而 r.ParseMultipartForm() 默认只在调用 c.FormFile() 或显式解析时才执行。没文件 → 不解析 → cache 空 → c.PostForm 永远返回空。
MaxMultipartMemory 不是总请求体限制，但会直接导致 400
MaxMultipartMemory 控制的是所有非文件字段（text、textarea、hidden）在内存中缓冲的上限，不是整个请求体大小。设太小（比如默认 32MB），含 50MB 描述文本的表单会直接触发 http: request body too large，连 handler 都进不去；设太大（如 512MB），恶意构造超长字段就能让服务 OOM。
- 它不约束文件内容——文件始终流式写磁盘
- 它只影响 text 类型字段的内存加载行为
- 必须配合 Nginx 的
client_max_body_size做双重拦截，否则攻击请求可能绕过 Gin 直接压垮反向代理
ShouldBindWith 是唯一可靠的大字段读取方式
别再依赖 c.PostForm 或 c.Request.PostForm。改用 c.ShouldBindWith(&v, binding.FormMultipart)，它会主动触发完整 multipart 解析，绕过缓存缺失问题，且自动处理大小写、空格、URL 编码等细节。
- 结构体字段 tag 必须严格匹配表单
name，例如Content string `form:"content"` - 对富文本字段，加
binding:"max=1000000"做字段级长度校验，比靠MaxMultipartMemory更精准 - 绑定后立即做 XSS 过滤（如
bluemonday），别等到入库才处理 - 避免在中间件里提前调
c.GetRawData()或读c.Request.Body，否则后续绑定失效
微服务间透传大字段时最容易忽略的链路断裂点
上游服务用 c.ShouldBindWith 正确读到了 800KB 的 JSON 描述，下游服务却收不到——大概率是因为你在转发时用了 json.Marshal + http.Post，但没设 Content-Length 或用了 chunked 编码，导致下游 Gin 因无法识别 body 边界而跳过解析。
- 跨服务传递大字段，优先走二进制协议（如 Protobuf）或带明确 length header 的 HTTP 请求
- 若必须用 JSON，确保上游写入时用
io.Copy流式发，下游用c.ShouldBindJSON而非手动io.ReadAll - 任何自定义 body 处理（比如加签名、压缩）都必须在
MaxBytesReader包装之后、实际读取之前完成，顺序错一步就全崩
MaxBytesReader、ParseMultipartForm、ShouldBindWith 这三者之间的协作时机——差半行代码，大字段就静默丢失。 
