Go HTTP/2 MaxConcurrentStreams 的连接级限流与跨连接并发边界

Go HTTP/2 的 MaxConcurrentStreams 只解决一个很具体的问题：一条 HTTP/2 连接上，客户端同时打开多少个流。它不是整个服务共享的并发总闸门。要限制服务进程承接的总请求，还要在 Handler、信号量或网关层做应用级治理。

先区分单连接上限和服务总并发

HTTP/2 把多个请求复用到一条连接里，每个请求对应一个 stream。MaxConcurrentStreams 描述的是这条连接允许客户端同时保持的流数量；值为零时，标准库使用至少 100 的默认值。这个限制会影响连接级调度，却不等于“这个 Go 进程最多只能处理 N 个请求”。

因此，排查时先问两个问题：请求是否真的复用到了同一条 HTTP/2 连接？服务端是否还允许客户端建立第二条连接？如果是两条连接，观察到的活动请求可以分别占用两份连接级配额。

把 MaxConcurrentStreams 放到 Server.HTTP2

Go 1.24 起，http.Server 提供 HTTP2 *http.HTTP2Config。服务端配置可以这样写：

srv := &http.Server{
    Addr: ":8443",
    HTTP2: &http.HTTP2Config{
        // 限制每条 HTTP/2 连接可同时打开的流数量。
        MaxConcurrentStreams: 64,
    },
}

// 这里仍需按项目已有方式加载证书并启动 HTTPS 服务。
err := srv.ListenAndServeTLS("server.crt", "server.key")
if err != nil {
    // 生产环境应把启动失败交给进程管理器或日志系统处理。
    log.Fatal(err)
}

关键不是把数字调得越小越好，而是先确认连接复用模型。长轮询、流式响应会长时间占用 stream；数值过小会让同一连接上的新请求等待或触发客户端建立更多连接。它也只在 HTTP/2 实际启用时有意义，HTTP/1.1 的并发控制不能靠这个字段替代。

跨连接请求为什么还能继续进入

官方文档把 MaxConcurrentStreams 定义为 Server 侧的连接配置，而 StrictMaxConcurrentRequests 属于 Transport。后者控制的是客户端 Transport 是否跨多个连接遵守并发限制，不能拿来当服务端的全局限流开关。服务端要得到“所有连接共享的 200 个业务请求”这种效果，应在 Handler 入口使用带容量的信号量，并在请求结束时释放。

var slots = make(chan struct{}, 200)

func handler(w http.ResponseWriter, r *http.Request) {
    select {
    case slots 

上线前的配置检查清单

如果配置为零，不要把它理解成“禁止并发”；它表示采用默认值。若目标是保护数据库、CPU 或下游 API，应用层名额还应配合请求超时、取消传播和指标记录，单独调整 HTTP/2 stream 数通常不够。

常见问题

MaxConcurrentStreams 是所有连接共享的吗？

不是。它是 HTTP/2 连接级参数，多条连接分别拥有自己的流上限；服务级总并发需要额外的应用层控制。

为什么设置 64 后请求数仍然超过 64？

先看客户端是否建立了多条 HTTP/2 连接，再确认请求是否实际走 HTTP/2；最后检查是否还有网关、代理或 Handler 内部的并发路径。

StrictMaxConcurrentRequests 能解决服务端总并发吗？

不能把它这样使用。它是 Transport 侧配置，服务端总并发应在 Handler、网关或资源池层实现。