应使用带缓冲的 channel（如 make(chan struct{}, 10)）作为并发令牌控制 goroutine 数量，避免仅依赖 sync.waitgroup 导致 oom 或连接雪崩。
Go 中用 sync.WaitGroup 控制并发分发的边界
不加控制地起 goroutine 发文件，轻则 OOM，重则目标节点 TCP 连接被打满、超时雪崩。sync.WaitGroup 本身不防并发爆炸，它只负责计数归零后通知，真正控速得靠 semaphore 或带缓冲的 channel。
- 推荐用带缓冲的
chan struct{}做并发令牌，比如make(chan struct{}, 10)限制最多 10 个并发上传 - 每次发文件前先
token ，上传完再 <code>，避免 goroutine 泄漏 - 别在 defer 里放
wg.Done()后还操作文件句柄——os.Open失败时wg.Add(1)已执行，但wg.Done()永远不会调，导致主协程死等
io.Copy 直传 vs 先读内存再 http.Post
小文件（os.Open + io.Copy 直接流式写入 HTTP body 最省内存；大文件若走 ioutil.ReadFile，会把整个文件塞进 Go 的堆，GC 压力陡增，还可能触发 runtime: out of memory。
- HTTP 上传务必设
req.Header.Set("Content-Type", "application/octet-stream")，否则某些接收端（如 Nginx proxy_pass）会拒绝二进制流 - 用
http.NewRequest("PUT", url, file)替代http.Post，后者强制用application/x-www-form-urlencoded，无法传原始字节 - 超时必须设：客户端用
&http.Client{Timeout: 30 * time.Second}，服务端也要配好 read/write timeout，不然一个卡住的连接会拖垮整批任务
节点失败时怎么避免全盘重试
批量分发最怕“一挂全停”。直接 for-range 节点列表 + 同步发，某个节点网络抖动或 503，整个流程就卡住。得让每个节点独立失败、独立重试，且失败不影响其他节点进度。
- 每个节点启动独立 goroutine，用
for i := 0; i 包裹上传逻辑，失败后 <code>time.Sleep(2 * time.Second)再试，别用指数退避——批量场景下时间一致性比单请求更重要 - 错误要分类：如果是
connection refused或timeout可重试；400 Bad Request或403 Forbidden属于配置错，重试无意义，直接记日志跳过 - 结果汇总别用全局 map + mutex，改用
sync.Map或每个 goroutine 返回struct{Node string; Err error}，主协程从 channel 收集
文件路径和节点地址里的常见陷阱
filepath.Join 和 url.JoinPath 看似安全，实则暗坑密集：Windows 路径反斜杠会破坏 HTTP URL；节点地址末尾多一个 /，可能导致 POST http://x.y.z//upload 这种非法路径。
立即学习“go语言免费学习笔记（深入）”；
- 本地路径统一用
filepath.ToSlash(filepath.Clean(path))转成正斜杠，再拼进 URL query 参数，别直接塞进 path 段 - 节点地址用
strings.TrimSuffix(nodeURL, "/") + "/upload"强制规范，避免双斜杠或漏掉 endpoint - 文件名含中文或空格？必须
url.PathEscape(filename)，否则http.Get会报parse "http://x/upload/你好.txt": invalid character ""
实际跑起来你会发现，并发数调到多少不取决于 CPU，而取决于目标节点的连接池大小和磁盘 IO；同一个文件发 10 个节点，网络耗时差异能到 3 倍以上——别指望所有 goroutine 同时结束。
