应使用 multipart.NewReader 边读边解析，避免 ParseMultipartForm 全量加载；需用 mime.ParseMediaType 安全提取 boundary，逐个完整消费 Part 并限制大小，自行管理临时文件与错误边界。
用 multipart.Reader 边读边解析，别全读进内存
Go 的 http.Request.ParseMultipartForm 会把整个 multipart body 加载到内存（或临时磁盘），上传大文件时极易 OOM 或拖慢服务。真正流式处理必须绕过它，直接用底层 multipart.Reader。
关键点：拿到 request.Body 后，用 multipart.NewReader 包装，再逐个读 Part，每个 Part 是一个可读流，你可以按需消费（比如写入文件、计算哈希、转发给其他服务）。
- 不要调用
r.ParseMultipartForm，否则 Go 会提前缓冲全部数据 -
multipart.NewReader(r.Body, boundary)的boundary必须从Content-Type头里准确提取，不能硬编码或瞎猜 - 每个
Part的Header包含Content-Disposition，需手动解析filename字段，注意 RFC 5987 编码（如filename*=UTF-8''%E6%96%87%E4%BB%B6.pdf）
如何安全提取 boundary 并避免解析失败
boundary 不是从 URL 或固定字符串来的，它藏在 Content-Type: multipart/form-data; boundary=xxxx 里。手撕字符串容易出错，Go 标准库提供了 mime.ParseMediaType。
错误做法是用 strings.Split(r.Header.Get("Content-Type"), "boundary=") —— 一旦 header 带空格、引号或参数顺序变化就崩。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
mime.ParseMediaType(r.Header.Get("Content-Type"))解析，返回的paramsmap 里取"boundary" - 如果解析失败或没找到
boundary，直接返回http.StatusBadRequest，别硬往下走 - 某些客户端（如旧版 curl）可能不带
Content-Type，此时应拒绝请求，而不是 fallback 到默认值
读 Part 时怎么防止卡死或失控
multipart.Part 是 io.Reader，但它是“粘性”的：一旦你读了几个字节，下次调用 NextPart() 就会跳过剩余内容。所以必须完整消费每个 part，否则后续 part 会错位甚至丢数据。
- 对每个
Part，用io.CopyN或带限速/超时的io.Copy写入目标（如文件、io.Discard），别只读前几 KB 就扔掉 - 设置单个 part 的大小上限（例如 10GB），用
io.LimitReader(part, maxPartSize)防止恶意超大字段耗尽磁盘 - 注意
part.FormName()和part.FileName()返回的是解码后的字符串，但内部读取仍需按原始字节流处理，别混用字符长度和字节长度做截断
为什么不用 ParseMultipartForm 还要自己管临时文件清理
绕过 ParseMultipartForm 意味着你放弃了 Go 自动管理的 MaxMemory 和临时磁盘缓冲。好处是可控，坏处是你得自己扛住磁盘满、权限失败、并发写冲突这些事。
- 如果写入本地文件，务必用
os.CreateTemp而非拼接路径 +os.Create，避免路径遍历 - 写完后记得
defer os.Remove(tempFile.Name())，但更稳妥的是用tempFile.Close()后立即os.Remove，防止进程崩溃残留 - 别依赖
runtime.GC()或debug.FreeOSMemory()来“释放内存”——它们对已分配的 buffer 没用，真正有效的是及时关闭Part和底层request.Body
边界值永远比文档写的更刁钻：比如 boundary 里含换行、filename 为空但 content 不为空、多个同名 file 字段嵌套在同一个 part 里……这些不会报错，但会悄悄让你的逻辑漏数据。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
