在 Go 的并发 HTTP 请求中，若未先检查 http.Response 是否为 nil 就直接调用 resp.Body.Close()，将触发 runtime panic；正确做法是始终优先判断 error，再安全使用 resp。
在 go 的并发 http 请求中，若未先检查 `http.response` 是否为 nil 就直接调用 `resp.body.close()`，将触发 runtime panic；正确做法是始终优先判断 error，再安全使用 resp。
这个问题的本质并非并发量过大导致资源耗尽，而是错误处理逻辑顺序不当引发的 nil 指针解引用。从 panic 栈追踪可见，崩溃发生在 processAndUnmarshalResponses 函数第 31 行（defer resp.Body.Close()），而此时 resp 为 nil —— 这通常意味着 HTTP 请求失败（如网络超时、DNS 解析失败、服务不可达等），http.DefaultClient.Do() 返回了 (nil, err)，但代码却在 err != nil 判断前就尝试 defer resp.Body.Close()，导致对 nil 值解引用。
✅ 正确的 HTTP 错误处理模式
必须严格遵循“先检查 error，再使用 resp”的原则：
func processAndUnmarshalResponses(resp *http.Response, err error, holder interface{}) error {
// ✅ 第一步：立即检查错误
if err != nil {
return err // resp 必然为 nil，绝不在此之后访问 resp
}
// ✅ 第二步：确保 resp 非 nil 后才操作
defer resp.Body.Close() // 安全：resp 已确认非 nil
// 后续解析逻辑（如 ioutil.ReadAll、json.Unmarshal 等）
body, err := io.ReadAll(resp.Body)
if err != nil {
return fmt.Errorf("failed to read response body: %w", err)
}
return json.Unmarshal(body, holder)
}⚠️ 并发场景下的额外注意事项
虽然本例 panic 直接源于错误处理顺序，但高并发（如 200+ goroutines）会加剧问题暴露：
- 大量并发请求易触发连接池耗尽、TCP TIME_WAIT 积压或服务端限流，从而增加 err != nil 的概率；
- http.Client 默认复用连接，但需显式配置超时与 Transport 以提升稳定性：
soundcloud.Client = &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
},
}? 如何快速定位类似问题？
- 静态检查：启用 go vet（它会警告 defer 在可能 nil 的指针上调用）；
- 运行时防护：在关键 resp 使用前加防御性判断（开发阶段临时辅助）：
if resp == nil {
return fmt.Errorf("unexpected nil response (error: %v)", err)
}- 日志增强：在 error 分支记录详细上下文（URL、状态码占位符、时间戳），便于复现失败请求。
✅ 总结
Go 的 HTTP 客户端设计要求开发者主动承担错误责任。resp 和 err 是互斥返回值：err != nil 时 resp 必为 nil，反之亦然。任何在 err 检查前对 resp 的访问（包括 defer resp.Body.Close()）都是危险的。修复该逻辑后，你的 worker() 即可稳定支撑数百 goroutines —— 并发本身不是问题，鲁棒的错误处理才是高可用服务的基石。
