短连接更吃资源是因为每次net.dial需完整tcp三次握手、tls握手、dns解析及系统调用，毫秒级延迟在高并发下迅速耗尽syscall和socket资源；go默认http.client禁用复用，须同时配置maxidleconns、maxidleconnsperhost和idleconntimeout才能启用连接池。
短连接为什么比长连接更吃资源
每次 net.Dial 都要走完整的 TCP 三次握手 + TLS 握手（如果启用了 HTTPS），再加上 DNS 解析、系统调用开销，单次连接建立在毫秒级——看似不长，但每秒几千次短连接会直接打满 syscall 和 socket 资源。Go 的 http.DefaultClient 默认禁用连接复用，http.Transport 的 MaxIdleConns 和 MaxIdleConnsPerHost 若为 0 或未设，就退化成纯短连模式。
用 http.Transport 复用连接必须配齐这三项
光设 MaxIdleConns 不够，漏掉任意一项都会让连接池形同虚设：
-
MaxIdleConns：全局最大空闲连接数，建议设为 100–1000（取决于并发量） -
MaxIdleConnsPerHost：单 host 最大空闲连接数，必须显式设置（默认 2，太小） -
IdleConnTimeout：空闲连接存活时间，建议 30–90 秒；设太长可能占着端口不放，太短导致频繁重建
示例：
client := &http.Client{<br> Transport: &http.Transport{<br> MaxIdleConns: 1000,<br> MaxIdleConnsPerHost: 100,<br> IdleConnTimeout: 60 * time.Second,<br> },<br>}
HTTP/1.1 Keep-Alive 不生效的常见原因
即使配了 http.Transport，连接仍被断开，往往是因为：
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 服务端返回了
Connection: close响应头（Nginx 默认某些错误码下会这样） - 请求头里手动加了
Connection: close（SDK 或中间件误设） - 服务端 HTTP/1.1 实现不规范，忽略
Keep-Alive请求头 - 客户端用了
http.NewRequest但没设Header.Set("Connection", "keep-alive")（其实 Go 默认会加，但某些代理或定制 transport 可能干扰）
验证方式：抓包看 TCP 连接是否复用，或打印 resp.Header.Get("Connection") 看是否为 keep-alive。
高频短连场景下，连接池预热和健康检查更关键
冷启动时第一批请求仍会卡在建连上。不要等第一次请求才触发连接池填充：
- 启动时用
http.Transport.DialContext预拨几个连接（注意别超限） - 对关键 host 主动发一个 HEAD 请求触发连接池初始化
- 避免用
http.DefaultClient，它无法定制且共享全局状态，容易被其他模块污染 - 若服务端支持 HTTP/2，优先启用——它天然多路复用，单连接承载多请求，比 HTTP/1.1 的 keep-alive 更省资源
HTTP/2 启用只需确保服务端支持且 client 不禁用：http.Transport.ForceAttemptHTTP2 = true（Go 1.8+ 默认开启）。
真正难的是服务端配合：哪怕客户端全配对了，只要服务端一纸 Connection: close 就前功尽弃。别只盯着自己代码里的 MaxIdleConns 调参，先确认对方响应头和负载均衡策略。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
