为何Golang net/http/transport中部分错误无法被unwrap识别？

你的问题本质是：用errors.Is(err, syscall.EPIPE)检测EPIPE错误来触发重试，但net/http的transport层返回的broken pipe错误是通过fmt.Errorf("net/http: HTTP/1.x transport connection broken: %v", err)生成的，因为用了%v而非%w，导致原始的syscall.EPIPE错误没有被加入错误链，errors.Is识别不出来，所以没法触发重试逻辑。

先搞懂%v和%w的核心区别 #

• %w是Go 1.13引入的专门用于错误包装的格式化动词，用它包装的错误会保留原始错误的关联关系，形成错误链，后续可以通过errors.Is/errors.As遍历识别原始错误。
• %v只是将原始错误的字符串表示嵌入到新错误中，相当于创建了一个完全独立的新错误，和原始错误没有任何关联，errors.Is自然找不到匹配。

net/http这么设计的原因 #

主要有两个核心考量：

1. 保持错误语义的抽象性：net/http希望暴露给上层的是「HTTP传输连接损坏」这个业务语义错误，而不是底层的系统调用错误（比如EPIPE）。如果用%w包装，上层代码很容易直接依赖syscall.EPIPE这种底层细节，一旦框架底层实现变化（比如在不同系统下用了其他错误类型），上层的重试逻辑就会失效。通过封装成抽象错误，框架能保证API的稳定性，上层只需要处理“连接坏了”这个通用信号。
2. 避免无意义的重试：EPIPE虽然常和连接中断相关，但并非所有情况都适合重试——比如对方服务器已彻底关闭连接池、网络链路完全中断等，盲目重试只会浪费资源。net/http通过封装错误，引导上层基于「传输连接损坏」这个更通用的判断依据来决定是否重试，而不是盯着某个具体的系统错误。

解决你的重试问题的可行方案 #

• 检查错误字符串（简单直接）：虽然不够优雅，但可以通过判断错误文本中是否包含"broken pipe"来触发重试：

  import "strings"
  
  if strings.Contains(err.Error(), "broken pipe") {
      // 执行重试逻辑
  }
  

• 自定义RoundTripper包装错误：实现自己的RoundTripper，在transport返回错误时，手动用%w重新包装原始错误，这样就能用errors.Is检测了：

  type WrappedTransport struct {
      rt http.RoundTripper
  }
  
  func (w *WrappedTransport) RoundTrip(req *http.Request) (*http.Response, error) {
      resp, err := w.rt.RoundTrip(req)
      if err != nil {
          err = fmt.Errorf("transport error: %w", err)
      }
      return resp, err
  }
  

内容的提问来源于stack exchange，提问作者Airenas