Go net/http HTTP2Config 怎么控制 HTTP/2：协议启用、并发流与兼容验证

把 Go 服务升级到 1.24 后，很多人会注意到 net/http.Server 多了 HTTP2 字段，却不确定它和协议开关、连接并发到底是什么关系。实际使用时，HTTP2Config 负责调 HTTP/2 的连接参数，Server.Protocols 和 Transport.Protocols 负责决定允许哪些协议；先分清这两层，配置才不会看起来生效、请求却仍按旧协议走。

如果目标是限制服务端一条 HTTP/2 连接上的并发流，配置 Server.HTTP2.MaxConcurrentStreams；如果目标是启用或禁用 HTTP/1、HTTP/2，则看 Server.Protocols 或 Transport.Protocols，不要把两个问题混成一个字段。

HTTP2Config 解决的是哪一层问题

Go 1.24 的 net/http 把高级 HTTP/2 参数放进 HTTP2Config。服务端最容易用到的是 MaxConcurrentStreams：它限制一个客户端在同一条 HTTP/2 连接上可以同时打开的流数量。SendPingTimeout、PingTimeout 和 WriteByteTimeout 则分别对应健康检查、Ping 响应和写出停滞。

这几个字段不会替你选择协议。HTTPS 场景下，Server 和默认传输层通常会自动启用 HTTP/2；要明确控制 HTTP/1 与 HTTP/2 的组合，应使用 Protocols。这也是排查“配置写了但协议没变”时最先要确认的边界。

服务端限制并发流的最小写法

package main

import (
    "fmt"
    "net/http"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "ok")
    })

    server := &http.Server{
        Addr:    ":8443",
        Handler: mux,
        HTTP2: &http.HTTP2Config{
            MaxConcurrentStreams: 128,
        },
    }
    _ = server
}

这段配置只表达一个意图：服务端每条 HTTP/2 连接最多允许 128 个并发流。证书加载、ListenAndServeTLS 以及业务处理器仍由应用负责。不要把 128 理解成全局并发上限；多个客户端连接各自都有一条流计数。

零值和服务端边界

不设置 MaxConcurrentStreams 时，net/http 使用文档规定的默认行为，文档说明服务端默认值至少为 100。生产环境不应只看代码中的零值，而要结合客户端连接数、单连接复用情况和服务端排队指标决定是否显式设置。

协议开关与 HTTP2Config 不要混用

Server.Protocols 和 Transport.Protocols 是协议集合；HTTP2Config 是 HTTP/2 参数集合。Go 1.24 还支持把 UnencryptedHTTP2 放入协议集合，让服务端接收明文 HTTP/2，但这属于协议选择，不是把 HTTPS 的 HTTP/2 参数搬到明文连接。

客户端如果使用自定义 Dial、DialTLS、DialContext 或自定义 TLSClientConfig，传输层默认会更保守，可能不再自动尝试 HTTP/2。需要保留尝试行为时，检查 ForceAttemptHTTP2；这里的配置字段原样写作 Transport.HTTP2，再用实际请求验证，而不是只打印配置结构。

transport := &http.Transport{
    ForceAttemptHTTP2: true,
    HTTP2: &http.HTTP2Config{
        PingTimeout: 15 * time.Second,
    },
}
client := &http.Client{Transport: transport}

验证时可以从服务端处理器记录 r.Proto 与 r.ProtoMajor，并将它们与客户端连接方式一起观察。只看到 HTTP/2.0 才能说明本次请求确实走了 HTTP/2；配置字段存在不等于连接已经协商成功。

常见误区：调大流数不等于提升吞吐

并发流上限只是连接级门槛。后端数据库连接池、请求处理 goroutine、响应写出速度仍可能成为瓶颈。把数值从 128 调到 1024，可能让更多请求进入处理阶段，也可能把压力直接推给下游。

另一个容易忽略的点是参数作用范围。HTTP2Config 的字段在服务端与客户端之间并非都同样适用，尤其 MaxConcurrentStreams 的文档说明主要针对服务端。阅读字段注释和实际连接行为，比复制一组“推荐参数”更可靠。

发布前用三步确认配置真的生效

1. 先确认运行时版本至少包含 Go 1.24 的 net/http.HTTP2Config，避免编译环境和部署环境不一致。
2. 再分别检查协议集合和 HTTP/2 参数：协议问题看 Protocols，并发与健康参数看 HTTP2。
3. 最后从实际请求记录 r.Proto，配合连接数、流拒绝和下游延迟观察结果，确认调整没有把压力转移成排队。

相关问题

HTTP2Config 能不能单独开启 HTTP/2？

不能。它用于配置 HTTP/2 行为；是否支持 HTTP/2 要看自动协商或 Protocols 设置。

MaxConcurrentStreams 是整个服务的并发上限吗？

不是，它是单条 HTTP/2 连接上的流上限。多个连接会分别计数。

为什么自定义 Transport 后 HTTP/2 不见了？

自定义拨号或 TLS 配置会让 Transport 默认采取保守策略。检查 ForceAttemptHTTP2，并用请求的 Proto 做最终验证。

小结

把 Go 1.24 的 HTTP/2 配置拆成两件事就不容易出错：Protocols 决定“允许什么协议”，HTTP2Config 决定“协议运行时怎么管”。先确定连接实际使用 HTTP/2，再针对单连接流数、Ping 和写出停滞做小步调整，通常比一次性堆满参数更容易复查和回滚。