Golang 中 net/http 默认的 Transport 有什么坑？

积累知识，胜过积蓄金银！毕竟在Golang开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Golang 中 net/http 默认的 Transport 有什么坑？》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

默认http.DefaultTransport生产环境不可直接使用：无超时导致goroutine永久阻塞，MaxIdleConnsPerHost默认仅2引发高频建连，IdleConnTimeout为0致fd泄漏，且不处理Cookie与重定向。

默认的 http.DefaultTransport 在生产环境几乎不可直接使用——它没设任何超时、连接池极小、空闲连接永不释放，很容易导致请求堆积、连接耗尽、goroutine 泄漏。

不设超时，请求会永久卡死

默认 Transport 的 DialContext、TLSHandshakeTimeout、ResponseHeaderTimeout 全为 0，意味着：DNS 解析失败、TCP 连接卡住、TLS 握手挂起、服务端迟迟不发响应头……都会让 goroutine 一直阻塞，直到客户端被系统 kill 或进程重启。

• 不要指望 context.WithTimeout 包裹 client.Do 就能解决——它无法中断正在建连的 TCP 握手
• 必须显式配置 Transport 的各阶段超时，尤其是 DialContext（含 DNS + TCP）和 TLSHandshakeTimeout
• ResponseHeaderTimeout 控制从发完请求到收到第一个字节响应头的时间，防后端“只写不发”

连接池太小，高并发下频繁建连

默认 MaxIdleConns 是 100，MaxIdleConnsPerHost 是 2，这意味着：同一域名最多只缓存 2 个空闲连接；超过的请求全得新建 TCP 连接，TLS 握手开销大，延迟陡增，还容易触发服务端连接数限制。

• 线上建议至少设 MaxIdleConnsPerHost: 100，避免单 host 成为瓶颈
• IdleConnTimeout 默认是 0（永不超时），必须设为 30–90 秒，否则空闲连接长期占着 fd 不释放
• HTTP/2 下复用更激进，但前提是 Transport 没禁用它；别碰已废弃的 ForceAttemptHTTP2

没有自动处理 Cookie 和重定向逻辑

http.DefaultTransport 本身不管理 Cookie，也不干预重定向——这些行为由 http.Client 层控制。但很多人误以为 “用了 DefaultTransport 就等于用了 DefaultClient”，结果：client.CheckRedirect 没配，重定向跳 10 次才停；client.Jar 没设，登录态无法透传。

• Transport 只管“怎么连”，Cookie 和重定向是 Client 层职责，二者不能混为一谈
• 若需自定义跳转逻辑（比如只允许同域跳转），必须在 http.Client 上设 CheckRedirect 函数
• 需要维持会话时，务必给 client 显式赋值 http.CookieJar，别依赖默认 nil 值

真正难的不是把 Transport 配对，而是理解每个字段生效的位置：DialContext 管建连，TLSHandshakeTimeout 管握手，ResponseHeaderTimeout 管首字节，IdleConnTimeout 管连接回收——少设一个，就可能在线上某个边缘场景里静默拖垮整个服务。

今天关于《Golang 中 net/http 默认的 Transport 有什么坑？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！