Go 程序在高频发起 HTTP GET 请求时因忽略错误导致 response 为 nil，进而触发 panic；根本原因是未检查 client.Do() 返回的 error，直接访问 response.Status 引发空指针解引用。
go 程序在高频发起 http get 请求时因忽略错误导致 response 为 nil，进而触发 panic；根本原因是未检查 `client.do()` 返回的 error，直接访问 `response.status` 引发空指针解引用。
该问题并非由“高延迟”本身引起，而是典型的 Go 错误处理疏漏：原代码中 response, _ := client.Do(req) 忽略了可能的错误（如 DNS 解析失败、连接超时、协议不可用等），当请求因底层网络问题（例如 dial tcp: Protocol not available）失败时，response 为 nil，但后续仍执行 response.Status，最终触发 panic: runtime error: invalid memory address or nil pointer dereference。
关键修复：始终检查 error
必须显式捕获并判断 client.Do() 的返回错误，禁止使用 _ 忽略 error：
response, err := client.Do(req)
if err != nil {
fmt.Printf("HTTP request failed after %s: %v\n", time.Since(start), err)
continue // 或按需重试/记录/退出
}
defer response.Body.Close() // 推荐 defer，确保关闭
fmt.Printf("HTTP request took %s. Status: %s\n", time.Since(start), response.Status)额外优化建议（提升健壮性与资源效率）：
- ✅ 复用 HTTP Client：每次循环新建 &http.Client{} 会创建独立 Transport，导致连接池、goroutine、文件描述符无节制增长（日志中大量 persistConn.readLoop/writeLoop goroutine 即由此引发）。应将 client 提升为包级或函数外变量，复用连接池。
- ✅ 配置合理的 Transport：启用连接复用、设置超时、限制并发连接数，避免耗尽系统资源：
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 5 * time.Second,
IdleConnTimeout: 30 * time.Second,
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
// 禁用 Keep-Alive 可能适得其反（增加握手开销），仅在明确需要时设置
},
}- ✅ 强制关闭响应体：即使请求成功，也必须调用 response.Body.Close()（推荐 defer），否则底层 TCP 连接无法释放，最终导致 too many open files 或连接阻塞。
- ✅ 避免滥用 req.Header.Add("Connection", "close")：该头会禁用 HTTP/1.1 持久连接，抵消 Transport 连接复用优势，除非服务端明确不支持 Keep-Alive。
总结：Go 的错误处理是显式且强制的。任何 I/O 操作（尤其是网络请求）都必须检查 error；同时，HTTP 客户端应作为长期复用对象设计，而非按需构造。忽视这两点，不仅会导致 panic，更会引发资源泄漏、连接耗尽等生产环境灾难。
