答案：Golang网络请求需处理连接超时、DNS失败、TLS握手错误等异常，应设置合理超时机制，通过类型断言判断错误并针对可重试错误实施指数退避策略，同时检查HTTP状态码并统一处理非2xx响应，最终将逻辑封装以提升复用性。
在使用 Golang 发起网络请求时，异常处理是保障服务稳定性的关键环节。由于网络环境的不确定性，连接超时、DNS 解析失败、服务器无响应等问题时常发生。如果不妥善处理这些异常，程序可能会阻塞、崩溃或返回不可预期的结果。下面介绍几种常见的网络请求异常类型及对应的处理策略。
常见网络异常类型
在 net/http 包中发起请求时，可能遇到以下几类错误：
- 连接超时：TCP 建立连接阶段耗时过长
- 传输超时：数据读写过程中超时
- DNS 解析失败：域名无法解析为 IP 地址
- 连接被拒绝或重置：目标服务未监听或主动断开
- SSL/TLS 握手失败：证书问题或协议不匹配
- HTTP 状态码非 2xx：服务端返回错误（如 404、500）
这些错误通常以 error 形式返回，需要逐层判断并处理。
设置合理的超时机制
默认的 http.Client 没有超时限制，可能导致请求长时间挂起。应为客户端配置明确的超时时间：
立即学习“go语言免费学习笔记（深入）”；
client := &http.Client{
Timeout: 10 * time.Second,
}
resp, err := client.Get("https://example.com")
if err != nil {
log.Printf("请求失败: %v", err)
return
}
defer resp.Body.Close()
更精细的控制可通过 Transport 设置：
client := &http.Client{
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 5 * time.Second,
ResponseHeaderTimeout: 5 * time.Second,
ExpectContinueTimeout: 1 * time.Second,
},
Timeout: 15 * time.Second,
}
这样可以分别控制连接、TLS 握手和响应头接收等阶段的等待时间。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
对错误类型进行判断与重试
不是所有错误都适合重试。例如 DNS 失败或证书错误通常不会因重试而改善，但连接超时或 5xx 错误可尝试有限次重发。
利用 type assertion 判断底层错误类型：
resp, err := client.Do(req)
if err != nil {
if e, ok := err.(net.Error); ok && e.Timeout() {
log.Println("请求超时")
} else if e, ok := err.(*url.Error); ok {
if _, ok := e.Err.(*net.DNSError); ok {
log.Println("DNS 解析失败")
}
}
// 其他错误处理
return
}
对于可重试场景，建议结合指数退避策略：
for i := 0; i < 3; i++ {
resp, err := client.Do(req)
if err == nil && resp.StatusCode == http.StatusOK {
// 成功处理
break
}
time.Sleep(time.Duration(1<<i) * time.Second)
}
统一处理 HTTP 非成功状态
即使请求成功（无 error），HTTP 响应也可能携带错误状态码。需手动检查：
if resp.StatusCode >= 400 {
body, _ := io.ReadAll(resp.Body)
log.Printf("HTTP 错误 %d: %s", resp.StatusCode, string(body))
return fmt.Errorf("server returned %d", resp.StatusCode)
}
也可以使用 resp.IsSuccess() 或类似逻辑封装判断。
基本上就这些。良好的网络异常处理依赖于全面的错误覆盖、合理的超时设定和有针对性的重试机制。在实际项目中，建议将公共逻辑抽象成中间件或客户端封装，提升代码复用性和可维护性。
