Go语言启用HTTP/2必须使用TLS，调用http.ListenAndServeTLS或配置TLSConfig后自动启用，无需导入http2包或手动配置；纯HTTP（ListenAndServe）永远只运行HTTP/1.1。
Go 语言开启 HTTP/2 不需要手动导入 http2 包，也不用调用 http2.ConfigureServer —— 只要走 TLS，它就自动开了。这是 Go 1.8+ 的默认行为，不是可选项。
为什么 http.ListenAndServe() 永远跑不了 HTTP/2
因为 HTTP/2 协议规范（RFC 7540）虽允许明文 h2c，但 Go 标准库从不支持。所有 http.ListenAndServe 调用都强制降级为 HTTP/1.1，哪怕你硬塞 NextProtos: []string{"h2"} 也无效。
常见错误现象：
- 浏览器 DevTools Network 标签里 Protocol 列始终显示
http/1.1 -
curl -v --http2 https://localhost:8443报错http2: unsupported scheme - 服务端日志里看不到
HTTP/2.0连接提示
根本原因：没走 TLS。Go 不协商 h2，除非底层是 https:// 且 TLS 握手成功。
立即学习“go语言免费学习笔记（深入）”；
必须用 http.ListenAndServeTLS() 或配置 TLSConfig
两种等效写法，任选其一即可触发 HTTP/2 自动启用：
http.ListenAndServeTLS(":8443", "server.crt", "server.key", nil)- 或显式构造
http.Server并设置TLSConfig后调用server.ListenAndServeTLS()
注意：
- 证书文件（
server.crt和server.key）必须可读，路径不能出错 - Go 1.8 起无需手动设置
TLSConfig.NextProtos，标准库已内置[]string{"h2", "http/1.1"} - 若手动设置了
NextProtos却漏掉"http/1.1"，老客户端可能直接断连
客户端怎么确认用了 HTTP/2
标准 http.Client 默认支持 HTTP/2，但前提是请求 URL 是 https:// 且服务端 ALPN 协商成功。不需要改 Transport.TLSNextProto。
验证方式：
- Chrome 访问
https://localhost:8443/ping→ DevTools Network → 看 Protocol 列是否为h2 -
curl -v --http2 https://localhost:8443/ping --insecure→ 查看响应头是否有ALPN, offering h2 - 服务端 handler 中打印
r.Proto，输出应为HTTP/2.0
如果用自签名证书，curl 必须加 --insecure，浏览器需临时加启动参数绕过证书警告（开发阶段可用）。
别碰 h2c，也别信“手动开启”教程
所谓 “用 golang.org/x/net/http2 手动启用 h2c” 是误导。Go 标准库从未实现 h2c，第三方库（如 caddyserver/caddy）或代理（如 nginx）才能做这件事。生产环境强行上 h2c 会引入额外 TLS 终止点、连接复用失效、ALPN 不一致等问题。
真正容易被忽略的点：
- 证书私钥权限错误（比如
0644而非0600）会导致ListenAndServeTLS静默失败 - 监听地址写成
http://localhost:8443而不是:8443，会报address invalid类错误 - 用
http.Serve+tls.Listener时忘了传tls.Config，HTTP/2 不会生效
