Go multipart.Reader 不能直接读大文件，因其非流式设计，会将整个 multipart 表单缓存进内存导致 OOM；需绕过 ParseMultipartForm，用 mime/multipart 手动解析、逐块读取并及时关闭 part。
Go multipart.Reader 为什么不能直接读大文件？
因为默认的 multipart.Reader 会把整个表单解析进内存，遇到几 GB 的文件或多个大文件同时上传，直接 OOM。它不是流式设计，而是「先读完再分块」——哪怕你只想要一个字段，它也得先把所有 multipart 边界和内容全缓存下来。
真正流式处理必须绕过 req.ParseMultipartForm()，改用底层 mime/multipart 包手动解析边界、逐块读取、及时丢弃不用的部分。
- 别调用
req.ParseMultipartForm()，它会强制把全部 body 读进内存 - 用
req.Body直接构造multipart.NewReader()，配合NextPart()迭代 - 每个
Part必须显式关闭（part.Close()），否则底层 reader 会卡住后续 part - 对非文件字段（如
title）也要io.Copy(io.Discard, part)清空，不然解析会中断
如何安全地把 multipart.Part 流式写入磁盘或对象存储？
关键不是「怎么写」，而是「怎么限速+防失控」。直接 io.Copy(dst, part) 看似简单，但没做任何防护：文件名未校验、大小无上限、临时目录可能爆满、恶意构造的超长 filename 可能导致路径穿越。
- 在
NextPart()后立刻检查part.Header.Get("Content-Disposition")，提取filename并做白名单校验（比如只允许^[a-zA-Z0-9._-]{1,256}$） - 用
io.LimitReader(part, maxFileSize)包一层，超过阈值就返回错误并break - 写磁盘时用
os.CreateTemp()生成随机临时文件，写完再os.Rename()，避免竞态和覆盖 - 如果写对象存储（如 S3），优先用分段上传（
PutObject不适合大文件），且每段需设ContentLength，不能传-1
http.Request.Body 被提前读取导致 multipart 解析失败？
这是最隐蔽的坑：只要你在调用 multipart.NewReader() 前碰过 req.Body（比如打日志、解 gzip、甚至 req.Header.Get() 某些中间件里隐式读 body），body 就可能被消费掉，后续 multipart 解析直接返回 EOF 或空 Part。
- 确认没有中间件（如 logging、auth、gzip）提前读取
req.Body；如有，必须用req.Body = ioutil.NopCloser(bytes.NewBuffer(buf))重置（但注意内存开销） - 调试时别用
io.ReadAll(req.Body)打印原始 body —— 它不可逆 - 用
req.MultipartReader()替代手动生成multipart.NewReader()，它内部做了更稳妥的 body 状态检查 - 本地测试时用
curl -F 'file=@/path/to/big.zip' http://localhost:8080/upload，避免浏览器自动加额外 header 干扰
并发上传多个大文件时，为什么 NextPart() 会卡住或漏 part？
不是并发本身的问题，而是 multipart 协议要求严格按顺序解析：每个 part 必须完整读完（包括结尾边界），否则下一个 NextPart() 就找不到起始边界，表现为卡死或跳过。
- 每个
Part必须调用part.Close()，它会帮你在 buffer 里「吃掉」该 part 结尾的--boundary行 - 不要用
io.CopyN()或io.ReadFull()截断 part，除非你手动处理边界字符串 - 如果某个 part 出错（如磁盘满），仍要调用
part.Close()，否则后续 part 无法解析 - 高并发下建议限制最大并发解析数（比如用
semaphore控制同时处理的Part数量），防止 goroutine 泛滥和 fd 耗尽
边界字符串解析、part 生命周期管理、body 可读性状态——这三处不显眼，但任一出错都会让流式上传退化成内存炸弹。别信「只要不用 ParseMultipartForm 就安全」这种简化结论。
