Go反向代理中复用http.Transport实例是否合理？

我基于Gin框架实现了HTTP反向代理中间件，核心代码如下：

挂载中间件的代码：

app := gin.New()
app.Use(proxy.ReverseProxy("127.0.0.1:8008"))  // 挂载ReverseProxy中间件

当前采用复用全局transport的实现：

var transport *http.Transport

func init() {  // 创建Transport实例
   transport = &http.Transport{
     // 配置参数
   }
}

func ReverseProxy(targetServer string) gin.HandlerFunc {
   return func(c *gin.Context) {
      proxy := &httputil.ReverseProxy{
         Transport: transport,             // 复用Transport实例
         // 配置参数
      }
      proxy.ServeHTTP(c.Writer, c.Request)
   }
}

另一种每次请求新建Transport的实现：

func ReverseProxy(targetServer string) gin.HandlerFunc {
   return func(c *gin.Context) {
      // 创建新的Transport实例
      transport = &http.Transport{
        // 配置参数
      }
      proxy := &httputil.ReverseProxy{
         Transport: transport,            // 使用新的Transport实例
         // 配置参数
      }
      proxy.ServeHTTP(c.Writer, c.Request)
   }
}

我的疑问是：复用单个http.Transport实例用于httputil.ReverseProxy是否正确？还是需要在每次请求时新建Transport实例？哪种方案更优？

目前我采用复用方式，因为能获得性能提升，它似乎会复用已创建的TCP连接，但我不确定高负载场景下的表现，是否会出现将无关响应返回给其他客户端的问题？

解答 #

复用单个http.Transport是正确且推荐的做法 #

• http.Transport的设计初衷就是支持并发复用，它内部维护了TCP连接池，会自动复用空闲连接，避免每次请求都建立新TCP连接的握手开销，这是提升代理性能的关键。
• 完全不用担心高负载下出现响应串流的问题：http.Transport本身是goroutine安全的，内部会为每个请求独立处理数据流，确保不同客户端的请求/响应不会混淆，官方文档明确说明它可以被多个goroutine同时调用。

每次请求新建Transport的方案存在严重弊端 #

• 性能极差：每次新建Transport会导致TCP连接无法复用，每个请求都要经历TCP三次握手、TLS握手（如果是HTTPS），高负载场景下会产生大量短连接，引发大量TIME_WAIT状态的连接，快速耗尽系统端口资源，导致服务无法处理新请求。
• 代码存在竞态风险：你给出的代码中使用了全局变量transport，每次请求都会覆盖它，并发场景下多个请求会同时修改该变量，导致不同的httputil.ReverseProxy实例可能拿到错误的Transport，引发不可预测的问题。

额外优化建议 #

• 复用Transport时，可以根据业务场景调整连接池参数，比如MaxIdleConns（最大空闲连接数）、MaxIdleConnsPerHost（每个主机的最大空闲连接数），让连接池更适配高负载场景。
• 还可以进一步复用httputil.ReverseProxy实例，而不是每次请求新建：因为ReverseProxy本身也是goroutine安全的，提前初始化好实例后直接复用，能减少对象创建开销，进一步提升性能。

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