用 sync.WaitGroup 控制并发上传的生命周期
协程启动后不等它跑完就退出，是多文件上传最常遇到的“上传没报错但文件全丢了”的根源。Go 不会自动等待 goroutine 结束，必须显式同步。
常见错误现象：main 函数结束，程序直接退出，http.Post 还没发出去；或只传了前几个文件就停了。
- 在启动上传协程前调用
wg.Add(1)，每个文件对应一次 Add - 在上传函数末尾（无论成功失败）调用
wg.Done()，别漏在 error 分支里 -
wg.Wait()放在所有go uploadFile(...)之后、main返回之前
别用 time.Sleep 代替 WaitGroup —— 网络延迟不可控，休眠短了丢文件，长了浪费时间。
http.Client 要复用，别在循环里 new
每个 http.Client 默认带自己的连接池和超时控制。在 for 循环里反复 &http.Client{}，会导致 TCP 连接激增、端口耗尽，甚至触发 dial tcp: lookup xxx: no such host 这类看似 DNS 实际是资源不足的错误。
立即学习“go语言免费学习笔记（深入）”；
使用场景：上传几十个文件到同一域名（如 S3 兼容接口、自建 minio）时尤其明显。
- 全局或函数外声明一个
client := &http.Client{Timeout: 30 * time.Second} - 需要定制 Transport（比如设置
MaxIdleConnsPerHost）时，改client.Transport，不要重造 client - 如果上传目标跨多个域名且策略差异大，才考虑按域名分 client，但依然要复用，不现场 new
默认 MaxIdleConnsPerHost 是 2，上传并发 >2 就会排队，建议设为上传最大并发数或更高（如 100）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
文件读取别用 os.Open + io.Copy 直传，小心内存和阻塞
直接 os.Open 后塞给 http.NewRequest 的 Body，看起来简洁，但实际是流式读取 —— 如果服务端响应慢、网络卡，goroutine 会卡在 io.Copy 上，协程无法释放，最终压垮 goroutine 调度器。
更麻烦的是：大文件（>100MB）用这种方式，可能因中间临时 buffer 或 GC 压力导致 OOM。
- 小文件（os.Open +
io.Copy，简单够用 - 中大文件（5MB–500MB）建议用
bufio.NewReaderSize(f, 1 控制单次读大小 - 超大文件或需断点续传，得自己分块读 +
multipart.Writer构建表单，不能依赖io.Copy全局转发
别忘了 defer f.Close() —— 协程里漏关文件句柄，Linux 下很快 hit too many open files。
上传失败时别只 log.Printf，得分类处理重试与跳过
并发上传里，单个文件失败（如 401、429、503、timeout）不该让整个流程中断，但也不能全当没事发生。日志打出来却不做任何判断，上线后根本不知道哪些文件丢了。
容易踩的坑：用 if err != nil { log.Println(err); continue }，结果 429 Too Many Requests 被当成普通错误跳过，后续请求继续撞墙。
- 对
net.ErrTimeout、context.DeadlineExceeded可重试（加time.Sleep指数退避） - 对
401 Unauthorized、403 Forbidden属于认证问题，重试无意义，应立刻停止全部上传 - 对
429 Too Many Requests，检查响应头Retry-After，没有就 sleep 1s 再试，最多 3 次 - 记录失败文件路径 + 错误码 + 时间戳到 slice，最后统一打印或写入失败清单文件
真正难的不是并发本身，是上传过程中每一步的错误语义你能不能识别清楚 —— HTTP 状态码、net 包错误、os 错误，各自代表什么，决定了你是重试、跳过，还是终止。
