Go HTTP2Config.StrictMaxConcurrentRequests 控制并发流上限时的连接策略

StrictMaxConcurrentRequests 决定 HTTP/2 流额度耗尽时客户端采用哪种连接策略：设为 true 时等待已有请求完成，设为 false 时，在所有已有连接都达到额度后允许增加连接。它是 Transport 侧的策略开关，不是一个可填写并发数的限流器，也不等于整个服务的业务并发上限。

官方文档：https://pkg.go.dev/net/http#HTTP2Config

先辨认并发流满额的使用场景

考虑一个聚合接口同时向同一上游发起许多请求。上游通过 HTTP/2 连接上的流额度约束单条连接的并发能力。如果已有请求尚未结束，后续请求就需要等待可用额度，或通过其他连接获得容量。此时的取舍是把压力留在本地等待，还是允许更多连接承载它。

我会先问上游是否允许横向增加连接，以及调用方能接受多久的排队。这里是配置判断方法，不是某次线上事故的实测记录。只看到响应慢，还不足以判断发生了流额度等待：DNS、握手、上游处理和响应体消费都可能贡献延迟。

本文讨论标准库 net/http 的 HTTP2Config；StrictMaxConcurrentRequests 字段在 Go 1.26 发行说明中列为新增能力。使用较旧工具链时，应先确认其标准库是否具有该字段，而不是仅因为已经存在 HTTP2Config 类型就认为所有字段都可用。

比较严格等待与允许增加连接

严格等待：在 Transport.HTTP2 中把 StrictMaxConcurrentRequests 设为 true。已有连接到达服务器的并发额度时，新请求等待其他请求完成。这个选择适合希望把协议层背压保留下来的客户端，但等待本身也要消耗调用方的时间预算。

允许增加连接：使用 false，即布尔字段的零值。当所有已有连接都已达到额度时，客户端可以通过额外连接继续承载请求。这并没有突破某条连接的协议额度，而是改变了连接池的扩展选择。能否获得实际收益仍取决于连接约束和上游容量。

两者都不是无条件更快。等待策略可能拉长排队；增加连接会引入连接建立和维护成本，也可能把瓶颈转移到上游。不能只根据选项名称中的 Strict 就把它当成性能优化开关。

区分流额度连接数和业务并发

HTTP2Config 同时用于 Server 和 Transport，具体字段的适用对象却不同。MaxConcurrentStreams 用于服务端；StrictMaxConcurrentRequests 用于客户端 Transport。客户端把 MaxConcurrentStreams 写进自己的配置，并不能要求远端按这个数字提供并发流。

连接数量还应与流数量分开。Transport.MaxConnsPerHost 管理每个主机的连接总量；MaxIdleConnsPerHost 管理保留的空闲连接数量。它们都不是“最多同时执行业务请求”的直接表达。尤其不要把提高空闲连接参数当成提高 HTTP/2 流额度的办法。

若业务要求整个进程最多允许一批请求进入上游调用，应在应用侧设计并发闸门和有界等待队列。多个 Client、多个 Transport、多个进程或多个实例不会因为某个布尔开关而自动共享一个业务配额。协议策略与应用容量控制应同时有明确归属。

按约束配置可复用的客户端

下面给出一个独立客户端构造器，两个策略共用相同的请求方法。它显式启用 HTTPS 的 HTTP/2 支持，同时保留 HTTP/1，避免把“设置 HTTP2 参数”误认为“必然协商为 HTTP/2”。超时值仅作示例，应按业务预算调整。代码没有进行请求或基准测试。

package upstream

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

// NewClient 在首次请求前固定策略，返回的客户端应复用
func NewClient(strict bool) (*http.Client, *http.Transport) {
    tr := http.DefaultTransport.(*http.Transport).Clone()
    tr.Protocols = new(http.Protocols)
    tr.Protocols.SetHTTP1(true)
    tr.Protocols.SetHTTP2(true)
    tr.HTTP2 = &http.HTTP2Config{
        StrictMaxConcurrentRequests: strict,
    }
    // 示例预算覆盖客户端请求生命周期，按真实业务调整
    client := &http.Client{Transport: tr, Timeout: 15 * time.Second}
    return client, tr
}

// Fetch 仅演示正常消费响应并关闭正文，避免遗漏清理
func Fetch(ctx context.Context, client *http.Client, address string) (string, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, address, nil)
    if err != nil {
        return "", fmt.Errorf("创建请求: %w", err)
    }
    resp, err := client.Do(req)
    if err != nil {
        return "", fmt.Errorf("请求失败: %w", err)
    }
    defer resp.Body.Close()

    // 这里丢弃正文仅为说明消费与关闭，不代表业务应忽略内容
    if _, err := io.Copy(io.Discard, resp.Body); err != nil {
        return resp.Proto, fmt.Errorf("读取响应: %w", err)
    }
    if resp.StatusCode = 299 {
        return resp.Proto, fmt.Errorf("上游状态码: %d", resp.StatusCode)
    }
    return resp.Proto, nil
}

当上游要求保留等待、调用方也有清晰截止时间时，可选 NewClient(true)。若上游明确允许连接池扩展，并且业务另有并发预算，可以比较 NewClient(false)。二者应在初始化阶段选择，不要在 Transport 已被多个请求使用后修改共享配置。

构造器用的是 DefaultTransport 的标准类型断言；若应用已替换全局 DefaultTransport 为自定义实现，应使用自己明确持有的 Transport 模板，不能直接照搬该断言。代码中的 HTTP2 配置为专用新配置；已有其他 HTTP/2 调优项的应用，应保留原有参数再修改目标字段。

拿到响应时可以记录返回的协议标识，确认实际请求是否使用 HTTP/2。它只能提供协议线索，不能直接证明请求是否等待过流额度。排查还要结合连接建立、请求耗时和上游侧的连接/活跃请求观察；这些是读者实施配置时的诊断依据，不是本文已经得到的测量结果。

识别不适用情况

没有实际使用 HTTP/2：保留 HTTP/1 回退不代表上游必然选择 HTTP/2。协议未协商成功时，不应期待这个字段改变行为。普通 http 地址也不能因为设置该字段就自动成为明文 HTTP/2。

服务端总容量不足：增加连接不能补充数据库、CPU 或下游服务的处理能力。如果排队原因是业务处理慢，应先控制入口压力和定位服务端瓶颈。严格等待同样不能代替服务端的租户限额或全局保护。

长响应持续占用资源：不要在拿到响应头后就假定请求完全结束。按接口语义消费响应体，并在退出路径关闭它；面对流式响应，应按流式业务设计时限，不能机械套用示例的十五秒客户端超时。

自管连接或第三方传输：本文的判断针对标准库 Transport 管理的连接池。自定义 RoundTripper、第三方 HTTP/2 客户端或自管连接需要查它们各自的字段与生命周期，不能仅因名称相近就套用相同结论。

用决策表收尾并回答相关问题

true 是否保证永远只有一条连接？不要这样理解。它决定并发额度满时是否依靠增加连接绕开等待，不是连接池在所有生命周期情形下的单连接承诺。

false 是否保证请求不会排队？不会。连接建立、连接数量限制、应用闸门和上游处理仍可能产生等待。

可以直接填一个全局并发数吗？不可以，这个字段是 bool。需要明确的数字限制时，应先说清限制对象是服务端连接上的流、客户端连接总量还是业务任务数，再选择对应机制。

选型时先写出上游允许的连接策略，再写调用方的等待预算，最后确定是否需要额外的应用闸门。发行说明入口：https://go.dev/doc/go1.26；字段实现定义：https://go.dev/src/net/http/http.go。