parsemultipartform是内存暴涨的根源，因其默认全量加载multipart body至内存或临时磁盘缓冲区，即使仅需一个文件字段也会为所有字段分配缓冲并多次拷贝数据；maxmemory仅限制内存部分上限，超出才落盘，但解析过程仍消耗大量临时buffer。
ParseMultipartForm 是内存暴涨的根源
Go 默认用 ParseMultipartForm 解析上传请求，它会把整个 multipart body 先加载进内存或临时磁盘缓冲区——哪怕你只想要一个文件字段，它也会为所有文本字段分配缓冲、反复拷贝数据。100MB 文件上传时 RSS 内存可能飙到 200MB+，不是因为业务逻辑，而是这个函数的默认行为。
- MaxMemory 参数只控制“内存部分上限”，超出后才落盘，但解析过程本身仍需大量临时 buffer
- 调用
ParseMultipartForm(32 并不等于“最多用 32MB”，实际峰值常翻倍 - 如果表单含多个字段（比如 5 个文本框 + 1 个文件），
ParseMultipartForm会全部解析，哪怕你只处理file字段
改用 multipart.NewReader 流式读取
绕开 ParseMultipartForm，直接用 multipart.NewReader 手动迭代每个 Part，只处理目标文件字段，其余全丢弃。这才是真正可控的流式方案。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 先从
r.Header.Get("Content-Type")提取 boundary，再构造multipart.NewReader(r.Body, boundary) - 循环
reader.NextPart()，对每个part检查part.Header.Get("Content-Disposition")是否含filename= - 非文件字段用
io.Copy(io.Discard, part)忽略，避免内存累积 - 目标文件字段调用
part.Open()得到io.Reader，再用io.Copy(dst, partBody)直接写入磁盘或转发
http.MaxBytesReader 必须放在最外层
很多人在 handler 里做大小校验，但恶意请求可在 multipart 解析前就耗尽内存——比如伪造超长 boundary 或畸形头部，multipart.NewReader 内部仍会尝试解析并分配 buffer。
- 必须在路由或中间件最开始就包装：
r.Body = http.MaxBytesReader(w, r.Body, 1（例如限制 1GB） - 这个包装要早于任何
multipart.NewReader或ParseMultipartForm调用，否则无效 - 错误时立即返回
http.StatusRequestEntityTooLarge，不要继续执行后续逻辑
上传目标选磁盘还是内存？别混用
中转类场景（如直传 S3）和处理类场景（如抽帧、校验哈希）策略完全不同，混用会导致双倍 IO 和内存暂存。
- 纯中转：用
io.Copy(s3Uploader.Body, partBody)直接流式转发，不落地、不缓存 - 需处理：用
os.CreateTemp("", "upload-*.tmp")创建临时文件，写完立刻Close()，后续操作用新os.Open句柄 - 绝对不要用
bytes.Buffer接整个文件——它在堆上不断扩容，GC 不会立刻回收，且无法限流 - 并发批量上传时，goroutine 数量应受信号量控制，而非无限制启动；每个 goroutine 内部 buffer 复用可用
sync.Pool
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
