Go HTTP 协议集合怎么在客户端和服务端共用配置

在 Go 1.24 及以上，net/http 用 http.Protocols 表示 HTTP 协议集合。要让客户端和服务端遵守同一套协议策略，关键不是把一个指针到处传，而是先定义一份清晰的策略，再分别挂到 http.Transport.Protocols 与 http.Server.Protocols。下面的示例允许 HTTP/1 和 TLS 上的 HTTP/2，明确关闭明文 HTTP/2，适合生产环境先收紧边界。

把协议意图收敛成一份共享策略

官方文档把协议集合拆成三个开关：HTTP1 覆盖 HTTP/1.0 与 HTTP/1.1，HTTP2 表示 TLS 连接上的 HTTP/2，UnencryptedHTTP2 表示未加密 TCP 上的 HTTP/2。生产服务通常只需要前两个，因此不要用“HTTP/2 已开启”推断明文 h2c 也可用。

package main

import "net/http"

// newHTTPProtocols 只表达团队允许的协议集合，不绑定某个具体端点。
func newHTTPProtocols() http.Protocols {
	var p http.Protocols
	// HTTP/1 兼容普通 TCP 和 TLS；HTTP/2 仅作为 TLS 场景能力。
	p.SetHTTP1(true)
	p.SetHTTP2(true)
	// 不调用 SetUnencryptedHTTP2(true)，保持明文 HTTP/2 关闭。
	return p
}

这里返回值而不是全局指针，是为了让调用方拿到自己的配置副本。http.Protocols 的零值是空集合，只有显式调用设置方法后才会包含对应协议；这种写法也方便在配置评审时一眼看出是否开放了明文 h2c。

同一策略要分别挂到客户端和服务端

两个字段的含义相近但不相同：服务端决定“我接受什么”，客户端决定“我愿意尝试什么”。配置时可以使用同一套构造函数，再把两个独立副本分别交给各自对象。

func buildHTTPPair(handler http.Handler) (*http.Server, *http.Client) {
	serverProtocols := newHTTPProtocols()
	transportProtocols := newHTTPProtocols()

	server := &http.Server{
		Addr:      ":8443",
		Handler:   handler,
		// Server.Protocols 是服务端接受集合，字段需要指针。
		Protocols: &serverProtocols,
	}

	base := http.DefaultTransport.(*http.Transport).Clone()
	// Transport 应复用并通过 Clone 派生，避免修改全局默认传输对象。
	base.Protocols = &transportProtocols
	client := &http.Client{Transport: base}
	return server, client
}

示例没有把同一个 *http.Protocols 同时交给两边。SetHTTP1 等方法会修改集合，分开持有可以避免后续某个组件为了兼容性临时改配置时影响另一个组件。

URL 和 TLS 条件仍决定实际协议边界

共享集合只表示能力范围，不能跳过连接条件。对客户端来说，https:// 请求才进入 TLS HTTP/2 的协商场景；http:// 请求不会因为 HTTP2 位为真就自动升级为加密 h2。如果确实要使用明文 HTTP/2，必须显式设置 SetUnencryptedHTTP2(true)，并同时评估网络边界、代理和中间设备的兼容性。

服务端的 Protocols 则控制监听端点能够接受的集合。证书、ALPN、监听器和对端支持情况仍然是最终连接是否采用 HTTP/2 的必要条件；配置集合本身不是协议协商结果。

用访问器做发布前检查

不要只打印结构体或依赖 nil 默认值。把检查写成小函数，既能放进配置测试，也能在启动日志中输出明确结论：

import "fmt"

func checkProtocols(p *http.Protocols) error {
	if p == nil {
		// nil 表示交给 net/http 默认策略，不能当成显式清单。
		return fmt.Errorf("protocols must be explicit")
	}
	if !p.HTTP1() || !p.HTTP2() {
		// 当前部署要求兼容 HTTP/1 和 TLS HTTP/2。
		return fmt.Errorf("HTTP1=%t HTTP2=%t", p.HTTP1(), p.HTTP2())
	}
	if p.UnencryptedHTTP2() {
		// 生产策略不允许未加密 HTTP/2，发现即阻止启动。
		return fmt.Errorf("unencrypted HTTP/2 is disabled by policy")
	}
	return nil
}

这段检查需要补充 fmt 导入；它的重点是把三种能力分别判断，而不是把协议名称拼成一段日志。正式发布前，服务端和客户端都应该通过同一组断言，随后再按环境决定是否允许某个端点使用不同策略。

常见问题

把 HTTP2 打开后，HTTP URL 会自动使用明文 HTTP/2 吗？

不会。HTTP2 表示 TLS 上的 HTTP/2；明文 HTTP/2 由独立的 UnencryptedHTTP2 开关控制。

为什么不直接复用一个 Protocols 指针？

因为集合有可变方法，客户端和服务端的协议职责也不同。用同一构造函数生成两个值副本，边界更清楚，后续修改不会产生隐式联动。

Protocols 为 nil 是错误吗？

不一定。nil 会触发 net/http 的默认行为，但默认值随 Server、Transport 和其他字段不同。若要求可审计的统一策略，应显式创建并检查集合。

最终判断可以压缩成一句话：共用的是“允许哪些协议”的策略，不是“客户端和服务端一定使用同一协议”的承诺；真正的连接结果还要看 URL、TLS、ALPN 以及对端能力。