Go 1.27 HTTP/1 连接复用改进会影响哪些客户端

如果一个 Go 客户端只关心 HTTP 状态码，却没有读完响应正文，Go 1.26 及以前经常会放弃这条 HTTP/1 连接。Go 1.27 的 net/http.Transport 会在关闭未读的 Response.Body 后，有限度地异步排空响应，让连接有机会继续复用。它改变的是连接管理细节，不是把所有请求都变成更快。

官方资料：https://go.dev/blog/http-connection-reuse

变化发生在“关闭但没读完”的那一刻

HTTP/1 的响应在同一条连接上按顺序到达。客户端只有读到当前响应的末尾，才知道下一份响应从哪里开始。过去，下面这种只取状态码的写法在 HTTP/1 场景下可能让下一次请求重新建连：

func statusCode(ctx context.Context, client *http.Client, url string) (int, error) {
	// 请求只关心状态码，但仍要关闭响应体，交给 Transport 做有限收尾。
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return 0, err
	}
	resp, err := client.Do(req)
	if err != nil {
		return 0, err
	}
	defer resp.Body.Close() // 不要把 Response.Body 留给连接池之外。
	return resp.StatusCode, nil
}

Go 1.27 的改进重点是：Close 之后，Transport 会尝试在约 50 毫秒或 256 KB 的保守范围内排空未读内容。上限意味着它不会为了复用连接而无止境下载一个巨大响应。

哪些客户端最容易看到变化

尤其容易忽略的是 JSON。json.Decoder 读完对象后，服务端若还发送换行，Reader 可能停在最后一个换行之前。过去这一字节也足以让 HTTP/1 连接不能直接交给下一次请求。现在它可能被自动消化，但应用仍不应把“连接复用成功”当成业务正确性的保证。

不要把兼容改进误读成全局性能承诺

Go 官方说明的结论是“多数程序无操作变化，或得到性能改善”。这不等于每个客户端都能获得固定倍数的加速。请求是否跨地域、响应大小、TLS 建连成本、并发模型和服务端是否发送 Connection: close，都会改变结果。

还要检查自定义 Transport。如果设置了 DisableKeepAlives: true，连接复用本身已被关闭；如果通过把 MaxIdleConns 设为 0 或为每个请求创建不同的 Client，主动绕开空闲连接管理，那么新行为也救不了连接池设计。对确实不适合复用的客户端，禁用 keep-alive 仍是明确选项，但应该有测量依据。

升级后用什么清单判断是否受益

1. 确认流量确实走 HTTP/1，而不是只看客户端使用了 net/http。
2. 确认每次请求都关闭 Response.Body，并记录读取或关闭错误。
3. 比较 Go 1.26 与 1.27 在相同服务端、相同响应体和相同 Transport 配置下的建连次数、复用次数与延迟。
4. 单独测试大响应和 Connection: close，不要只用空响应压测。

这个改动最适合被当作“减少一类容易漏掉的连接收尾代码”。升级时先保留简洁的请求写法，再用 httptrace 或连接指标确认收益；不要为了追求复用而手动把所有响应体读到无穷大。

相关问题

Go 1.27 之后还要手动 io.Copy(io.Discard, resp.Body) 吗？

通常不必把它作为默认模板。先关闭响应体，让 Transport 在有限预算内处理；只有业务明确需要读取完整正文时才完整读取。

这项变化会影响 HTTP/2 吗？

标题中的变化针对 HTTP/1 未读响应体。HTTP/2 通过流复用承载多个请求，边界不同，但应用仍要正确关闭响应体。

为什么升级后仍然没有复用连接？

优先检查 DisableKeepAlives、客户端是否复用、服务端的 Connection: close、响应是否超过有限排空范围，以及是否实际协商成 HTTP/1。