真正限制并发能力的不是goroutine数量，而是http连接池、文件句柄、内存缓冲区和目标服务响应能力；需显式配置http.transport参数、使用带背压与可退出的worker pool、分层容错及幂等设计。
并发数不是靠 goroutine 数量决定的
真正限制并发能力的不是开了多少 goroutine，而是底层资源——HTTP 连接池、文件句柄、内存缓冲区和目标服务的响应能力。用runtime.GOMAXPROCS 或盲目起 100 个 goroutine 只会让问题更隐蔽：连接打满、too many open files、GC 频繁卡顿，甚至触发上游 429 限流。
- 显式配置
http.Transport：把MaxIdleConns和MaxIdleConnsPerHost设为 200–500（根据压测调整），并设置IdleConnTimeout为 30s 防止空闲连接堆积 - 对同一域名大量请求时，Go 1.19+ 必须设
MaxConnsPerHost，否则单 host 连接数不受控 - 每个下载任务应使用独立的、带 timeout 的
http.Client，避免不同超时策略混用
worker pool 必须带背压与可退出
“一个 channel + N 个长生命周期 goroutine”是正确起点，但生产环境里它很容易变成黑洞：消息积压、协程 panic 后静默消失、进程无法优雅关闭。-
msgChannel缓冲区不能太小：设为MAX_CONCURRENT_ROUTINES × 2起步（如 5 个 worker 就用 10～50），太大则内存浪费，太小导致主循环阻塞在msgChannel - worker 必须用
for msg := range msgChannel循环，而非for { ，否则 channel 关闭后会 panic - 主 goroutine 收到
os.Interrupt后要先close(msgChannel)，再用wg.Wait()等待所有 worker 处理完当前任务，最后才退出
下载过程必须分层容错
一次下载涉及 HTTP 请求、磁盘写入、S3 上传、SQS 确认等多个环节，任一失败都可能导致消息丢失或重复。- 每个 I/O 操作都要检查 error，并区分可重试（网络超时、5xx）和不可重试（404、JSON 解析失败）；前者加指数退避重试，后者应进死信队列（DLQ）
-
DeleteMessage必须在所有下游操作成功后才调用；若失败，消息会在 Visibility Timeout 后重入队，此时要求downloadAndUpload幂等（例如 S3 Key 基于消息 ID 生成） - 大文件写入别用
io.Copy直连resp.Body：至少套一层bufio.NewWriter，极敏感场景改用io.CopyBuffer+ 1MB 自定义 buffer
最易被忽略的是：channel 关闭后，worker 中仍在执行的 resp.Body.Close() 或 file.Close() 可能 panic；所有资源清理逻辑必须包裹在 defer 里，并确保不依赖已关闭的通道或上下文。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
