Go MaxIdleConnsPerHost 能限制总并发连接数吗

不能。MaxIdleConnsPerHost 只控制每个主机最多保留多少条空闲的 keep-alive 连接，不统计正在拨号和正在处理请求的连接。要限制某个 host 的连接总数，应设置 MaxConnsPerHost；它覆盖拨号中、活跃和空闲三种状态，超过上限时新的拨号会等待。

把 MaxIdleConnsPerHost 当成并发闸门，是 Go HTTP 客户端连接池配置里最常见的误解。前者决定“请求结束后留多少连接复用”，后者才决定“这个 host 最多建立多少连接”。

先分清三个连接池参数

Transport 维护的是可复用的网络连接。一个请求结束后，连接可能回到空闲池；新请求也可能复用这条连接。下面这张关系图把三个参数放在同一个边界中，便于判断应该改哪一个。

因此，把 MaxIdleConnsPerHost 从 2 调到 100，主要是提高请求结束后的复用机会；它不会把同时发出的 100 个请求排成两条连接，也不会让活跃连接立即减少。

为什么 MaxIdleConnsPerHost 限不住正在使用的连接

“idle” 是连接状态，而不是请求数量。请求还没有读完响应体时，连接通常属于活跃状态；刚建立但尚未完成连接过程时，属于拨号中状态。这两类都不受 MaxIdleConnsPerHost 的直接约束。

这也是连接数观察结果容易误判的原因：把参数调小后，监控里短时间内的活跃连接仍可能很高；等请求结束，Transport 才会依据空闲池规则决定哪些连接留下。为了让连接真正回到池里，客户端必须复用同一个 Transport，并在处理完响应后关闭 resp.Body。

package main

import (
	"context"
	"fmt"
	"net/http"
	"time"
)

func fetch(ctx context.Context, client *http.Client, url string) error {
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return err
	}

	resp, err := client.Do(req)
	if err != nil {
		return err
	}
	defer resp.Body.Close() // 及时归还响应体，连接才有机会复用

	fmt.Println(resp.Status)
	return nil
}

func newClient() *http.Client {
	transport := &http.Transport{
		MaxIdleConns:        100, // 所有 host 共享的空闲连接上限
		MaxIdleConnsPerHost: 20,  // 单个 host 保留的空闲连接上限
		MaxConnsPerHost:     40,  // 单个 host 的拨号中、活跃、空闲连接总上限
		IdleConnTimeout:     90 * time.Second,
	}
	return &http.Client{Transport: transport}
}

这个配置的含义是：某个 host 最多保有 40 条 Transport 管理的连接，但请求数仍需结合协议判断。若使用 HTTP/1.1，连接通常对应一个正在处理的请求；若使用 HTTP/2，一条连接可以承载多个并发流。

需要总连接上限时怎么配置

使用 MaxConnsPerHost，并把它当作连接资源的上限，而不是业务任务的并发上限。官方定义覆盖 dialing、active、idle 三种状态；当连接数达到上限，新的拨号会阻塞，直到已有连接释放或请求失败。

如果你的目标是“最多同时处理 40 个业务任务”，更稳妥的做法是在业务层增加信号量；如果目标是“不要让客户端为同一个 host 建立过多 TCP/TLS 连接”，才使用 MaxConnsPerHost。两者可以同时存在，但解决的是不同层级的问题。

还要注意复用方式：不要在每次请求里创建一个新的 http.Transport。官方文档建议 Transport 只创建一次并复用，而且它可以被多个 goroutine 并发使用。否则每个 Transport 都有自己的连接池，单个实例上的上限无法代表进程整体行为。

连接复用和 HTTP/2 还要检查什么

第一，确认请求确实使用了目标 Transport。直接调用 http.Get 会走默认客户端；如果业务代码另有 client，参数可能根本没有生效。第二，确认 resp.Body.Close() 的路径覆盖成功响应和提前返回。第三，检查请求 URL 的 host 是否被端口、代理或不同域名拆成了多个连接池键。

最后区分 HTTP/1.1 与 HTTP/2：MaxConnsPerHost 限制的是连接条数，不是 HTTP/2 stream 数量。若需求是限制请求并发，应在调用入口做令牌控制；若需求是控制空闲连接占用，则调整 MaxIdleConnsPerHost 与 IdleConnTimeout。这两个目标不要用同一个参数硬凑。

常见问题

MaxIdleConnsPerHost 设为 0 是不是没有空闲连接？

不是。零值表示使用 DefaultMaxIdleConnsPerHost，当前官方文档给出的默认值是 2；它也不等于禁用连接复用。

MaxConnsPerHost 超限会直接返回错误吗？

通常不是立即报错，而是让新的拨号等待。等待多久取决于已有请求何时释放连接，以及请求自身的 context 或客户端超时。

只设置 MaxConnsPerHost 就能限制接口 QPS 吗？

不能。它限制连接资源，不限制单位时间内的请求数；HTTP/2 场景尤其明显。QPS 和业务任务并发需要在应用层单独控制。

排查 Go HTTP 连接数时，先问清楚要限制的是空闲连接、TCP/TLS 连接，还是业务请求。对应选择 MaxIdleConnsPerHost、MaxConnsPerHost 或业务层信号量，结果才不会互相误导。