应通过 http.Transport 限流和 channel 令牌控制并发：设 MaxIdleConns 与 MaxIdleConnsPerHost 均为 20，再用缓冲 channel（如 sem := make(chan struct{}, 10)）作并发令牌。
用 http.Client 控制并发下载，别直接开 100 个 goroutine
默认的 http.Client 没有并发限制，不加控制地启动大量 goroutine 下载文件，极易触发连接耗尽、DNS 超时或服务端限流。关键不是“能不能并发”，而是“怎么安全压并发”。
- 设置
http.Transport的MaxIdleConns和MaxIdleConnsPerHost（例如都设为 20），避免空闲连接堆积 - 用带缓冲的 channel 做并发令牌，比如
sem := make(chan struct{}, 10)，每个下载任务先sem 再发请求，完成后 <code><-sem - 务必设置
context.WithTimeout，否则单个失败请求可能卡住整个 goroutine 池 - 注意：重定向（
302）默认被http.Client自动跟随，若目标地址域名多变，需手动处理或禁用自动跳转防止 DNS 泛洪
上传大文件时用 io.Pipe + multipart.Writer 流式构造 body
把整个文件读进内存再上传，OOM 风险极高；用 os.Open 直接传给 http.NewRequest 又无法添加其他表单项。正确姿势是边读边写入 multipart body。
- 创建
pr, pw := io.Pipe()，用pw启动一个 goroutine 写入multipart.Writer，主流程从pr读取并提交 - 文件字段必须调用
w.WriteField("filename", name)显式写入文件名，否则服务端可能收不到原始名 - 如果服务端要求签名或预签名 URL，务必在启动 pipe 写入前完成所有鉴权计算——pipe 一旦开始写入就无法回退
- 别忘了在 pipe 写入 goroutine 结束时调用
pw.Close()，否则读端会永远阻塞
并发上传/下载中如何统一处理错误与进度回调
每个 goroutine 独立出错容易丢失上下文，全靠日志排查效率低。推荐用结构化错误通道 + 共享状态计数器。
- 定义
type TaskResult struct { ID string; Err error; Size int64 }，所有任务结束都发到同一个chan TaskResult - 用
sync.Map存储各任务当前已传输字节数（key = taskID），配合原子操作更新，供外部轮询进度 - 不要在 goroutine 里直接 panic 或 log.Fatal，会导致整个程序退出；错误统一由主 goroutine 收集后判断是否终止后续任务
- 若需取消全部任务，用
context.WithCancel创建父 context，每个子请求都传入该 ctx，并在收到 cancel 后主动关闭 pipe 或中断读取
os.Create 和 os.OpenFile 在并发写入时的坑
多个 goroutine 同时写同一个文件名，结果不是覆盖就是数据错乱。即使加锁，也无法解决写入顺序不可控的问题。
立即学习“go语言免费学习笔记（深入）”；
- 下载场景下，每个任务必须生成唯一临时文件名，如
fmt.Sprintf("%s.part%03d", baseName, i)，全部成功后再os.Rename合并 - 上传前校验本地文件存在性，用
os.Stat而非os.IsNotExist错误判断，因为后者在并发 stat+open 间隙可能误判 - 写入完成后务必调用
f.Sync()再f.Close()，尤其在 NFS 或某些云存储挂载点上，否则可能丢最后几 KB - Windows 下对正在写的文件调用
os.Remove会失败，应确保写 goroutine 完全退出后再清理临时文件
实际跑起来你会发现，瓶颈往往不在 Go 的 goroutine 调度，而在 DNS 解析延迟、TLS 握手复用率、磁盘 I/O 调度策略这些底层环节。调试时优先看 net/http/httptrace 的 trace 数据，而不是盲目加并发数。
