默认http.Transport在微服务调用中连接复用率低，因其按IP:Port精确匹配连接池键，而服务发现导致同一服务多IP解析，使连接分散；需自定义DialContext返回统一逻辑地址（如"svc-a:8080"）并调大MaxIdleConns/MaxIdleConnsPerHost、设IdleConnTimeout、禁用ForceAttemptHTTP2。
为什么默认的http.Transport在微服务间调用时连接复用率低
Go 默认的 http.DefaultTransport 确实启用了连接池，但它的复用逻辑依赖于 Host 和 Port 的精确匹配。微服务场景下常通过服务发现（如 DNS SRV、Consul）动态解析出多个 IP 地址（比如 svc-a-1.internal:8080、svc-a-2.internal:8080），即使目标服务名相同，只要底层 IP 不同，http.Transport 就认为是不同后端，各自维护独立连接池——结果就是连接分散、空闲连接快速超时、TLS 握手频繁。
根本原因在于：默认 DialContext 按 net.Addr.String()（即 "IP:Port"）做连接键，而非按服务逻辑标识（如 "svc-a:8080"）。
- 现象：
netstat -an | grep :8080 | wc -l显示大量TIME_WAIT或短命连接 - 关键配置项：
http.Transport.MaxIdleConnsPerHost对每个 IP 单独生效，不是全局配额 - 解决方向：接管
DialContext，让不同 IP 的请求复用同一组连接池
如何用自定义net.Dialer统一管理连接池键
核心不是重写 Dialer，而是控制连接池的“归组逻辑”。Go 1.19+ 支持在 http.Transport 中设置 Registry（需配合 http.RoundTripper 实现），但更直接的方式是：用 http.Transport.DialContext 返回一个“伪装地址”的 net.Conn，并在其 RemoteAddr() 方法中返回逻辑服务名（如 "svc-a:8080"），这样 Transport 就会把所有指向该服务的连接归入同一个池。
- 必须实现
net.Conn接口的RemoteAddr()和LocalAddr()，且RemoteAddr().String()要稳定返回逻辑地址（不能含 IP） -
DialContext内部仍用标准net.Dialer.DialContext建立真实 TCP 连接，只是包装一层 - 示例关键片段：
type logicalConn struct {
net.Conn
logicalAddr string
}
func (c *logicalConn) RemoteAddr() net.Addr {
return &fakeAddr{addr: c.logicalAddr}
}
type fakeAddr struct{ addr string }
func (a *fakeAddr) Network() string { return "tcp" }
func (a *fakeAddr) String() string { return a.addr }
// 在 DialContext 中：
return &logicalConn{
Conn: realConn,
logicalAddr: "svc-a:8080", // 统一逻辑地址
}
http.Transport 需要配套调整哪些参数
仅替换 Dialer 不够，Transport 的连接复用策略必须同步对齐，否则逻辑地址一致但连接仍被丢弃。
-
MaxIdleConns和MaxIdleConnsPerHost：建议设为0（不限制）或较大值（如1000），因现在“Host”已变成逻辑名，PerHost实际就是“每服务” -
IdleConnTimeout：建议保留（如30s），避免长时空闲连接占用资源；但注意它作用于逻辑连接池，不是单个 TCP 连接 -
KeepAlive：设为30s以上，配合服务端keepalive参数，防止中间设备断连 - 务必禁用
ForceAttemptHTTP2（除非确认服务端支持 HTTP/2），否则某些 TLS 握手失败会绕过自定义 Dialer
实际部署时最容易被忽略的兼容性问题
这套方案在多数 gRPC-Go、OpenTelemetry HTTP Exporter 等组件中能直接生效，但部分库会绕过 http.Transport 自行 Dial（比如老版本 database/sql 驱动、某些 Redis 客户端），此时需单独适配。
- DNS 解析必须由你的 Dialer 控制：不能依赖
http.Transport自带的Resolver，否则解析时机早于逻辑地址生成，导致 IP 已固化 - TLS 场景下，
tls.Config.ServerName仍需设为真实域名（如"svc-a.internal"），不能设成逻辑地址，否则证书校验失败 - 健康检查探针（如 Kubernetes liveness probe）若直连 Pod IP，会跳过你的逻辑地址封装，造成连接池割裂——应统一走服务名访问
真正麻烦的从来不是 Dialer 本身，而是服务网格里各种组件对“连接归属”的隐式假设。逻辑地址一旦定下，所有中间件、监控埋点、重试逻辑都得跟着对齐，否则指标就乱了。
