必须绕过parsemultipartform，改用req.multipartreader()流式解析：逐个nextpart()、校验name与filename、用io.copyn控制读取量、直接传part给sdk；并发时用带缓冲channel限流+context超时；文件名需手动解析content-disposition并安全转义；大文件上传强制走分块上传流程并管理upload id生命周期。
multipart/form-data 解析时内存暴涨怎么压？
Go 默认的 http.Request.ParseMultipartForm 会把整个文件先读进内存（maxMemory 参数控制上限），上传 500MB 文件却设了 32MB 缓存，直接触发 http: request body too large 或 OOM。必须绕过默认解析流程，用流式处理。
- 立即调用
req.MultipartReader()获取multipart.Reader，跳过ParseMultipartForm - 遍历
NextPart()，对Content-Disposition中name="file"的 part 做流式转发 - 用
io.CopyN或带 buffer 的io.Copy控制每次读取量（如 1MB），避免单次分配大内存 - 别用
part.Open()后直接传给对象存储 SDK —— 多数 SDK（如 aws-sdk-go-v2）支持io.Reader接口，直接传 part 即可
并发上传多个大文件时如何避免 goroutine 泄漏？
用户一次提交 10 个 2GB 文件，若每个都起 goroutine 调用 PutObject，又没做限流或超时控制，很容易打爆连接池或耗尽 goroutine 栈。
- 用带缓冲的 channel 做任务队列，例如
make(chan *UploadTask, 10)，配合固定数量 worker（如 3 个）消费 - 每个 worker 内部对
PutObject设置 context timeout：ctx, cancel := context.WithTimeout(req.Context(), 5*time.Minute) - worker 执行完必须调用
cancel()，否则 context 持有请求生命周期，导致 goroutine 无法回收 - 上传失败时，
part已被读取部分无法重放，需在 task 结构体里保存原始multipart.Part的 header 和 reader（用io.MultiReader+ bytes.Buffer 缓存头部）
文件名含中文或特殊字符，上传到 S3 兼容存储后乱码怎么办？
浏览器对 filename 字段的编码不统一：Chrome 用 RFC 5987（filename*=UTF-8''...），Safari 可能只传 raw 字节。Go 的 part.FileName() 内部调用 mime.BEncoding.Decode，但部分对象存储（如 MinIO、腾讯云 COS）对非 ASCII key 的 URL 编码要求严格。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 不要直接用
part.FileName()作为 object key —— 它可能返回空或解码失败 - 手动解析
part.Header.Get("Content-Disposition")，正则提取filename\*?=([^;]+)，再用url.PathUnescape解码 - 最终 key 统一转为小写 + UUID 前缀 + 安全文件名（用
strings.Map过滤非字母数字字符，保留.和-） - 上传后通过
HeadObject验证 key 是否与预期一致，不一致说明服务端做了自动转义，需调整生成逻辑
如何确保大文件上传中断后不残留半成品？
用户上传到 90% 时网络断开，对象存储里留下一个 4.5GB 的残缺 object，既占空间又无法访问 —— 这不是 Go 层能解决的，得靠对象存储的分块上传（Multipart Upload）机制。
- 禁用直传
PutObject，强制走CreateMultipartUpload→UploadPart→CompleteMultipartUpload流程 - 每个 part 用独立
io.LimitReader(part, partSize)切片（如 5MB），避免单 part 过大导致超时 - 上传中途失败，调用
AbortMultipartUpload清理所有已上传 part（注意：需持久化 upload ID 到 DB 或 Redis，超时后主动 abort） - 前端需支持断点续传：后端返回已成功上传的 part number 列表，前端跳过重试
真正麻烦的是 multipart upload ID 的生命周期管理 —— 它不像普通请求能绑定到 http.Request.Context，必须额外设计 TTL 清理任务，否则闲置 upload ID 积压会导致对象存储账单异常升高。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
