Go 的 crypto/tls 不负责启用 HTTP/2，HTTP/2 由 net/http 在 TLS 上通过 ALPN 自动协商；只需用 ListenAndServeTLS 或正确配置 TLSConfig（确保 NextProtos 包含 "h2" 和 "http/1.1"），Go 1.8+ 即自动启用 HTTP/2。
Go 的 crypto/tls 本身不“配置 HTTP/2”，HTTP/2 启用与否由 net/http 在 TLS 层之上自动协商决定；你只需正确配置 TLS，HTTP/2 就会自动生效（前提是走 HTTPS）。
为什么直接配 tls.Config 无法启用 HTTP/2？
HTTP/2 不是 TLS 的一个加密套件，而是应用层协议，它通过 TLS 的 ALPN（Application-Layer Protocol Negotiation）扩展在握手阶段协商。Go 的 http.Server 在调用 ListenAndServeTLS 或 ServeTLS 时，会自动注入 "h2" 到 tls.Config.NextProtos（从 Go 1.8 起默认行为）。但如果你手动 new 一个 tls.Config 并传给 http.Server.TLSConfig，又没显式保留或补全 NextProtos，就可能意外覆盖掉这个默认值。
- 常见错误：新建
tls.Config后只设Certificates，没碰NextProtos→ Go 会用空切片，ALPN 不带"h2"→ 客户端协商失败，降级为 HTTP/1.1 - 更隐蔽的坑：显式设置
NextProtos: []string{"http/1.1"}→ 彻底排除"h2"，哪怕证书和端口都对，也绝不会走 HTTP/2 - 注意：
http.ListenAndServe(":8080", h)根本不走 TLS，无论tls.Config怎么配，HTTP/2 都不可能出现
http.ListenAndServeTLS 是最简且最安全的启用方式
这是绝大多数场景下推荐的做法，它内部会自动处理 NextProtos、证书加载和 ALPN 注册，无需你干预 crypto/tls 细节。
- ✅ 正确示例：
http.ListenAndServeTLS(":8443", "server.crt", "server.key", handler) - ✅ 它等价于：创建默认
tls.Config→ 自动追加"h2"和"http/1.1"到NextProtos→ 加载证书 → 启动 TLS 监听 - ❌ 错误写法：
http.ListenAndServeTLS(":8443", "", "", handler)（空证书路径）→ 会 panic，因为没证书根本建不起 TLS 连接 - ⚠️ 注意：端口必须是 HTTPS 默认端口（如
:443或:8443），但不是硬性限制；关键是协议必须是 TLS，不是端口号
手动配置 http.Server.TLSConfig 时的关键点
当你需要定制 TLS 行为（比如限制版本、指定密码套件、启用客户端认证），就得自己构造 tls.Config 并赋给 http.Server.TLSConfig。此时必须确保 NextProtos 包含 "h2"，且顺序合理。
- ✅ 推荐写法：显式初始化
NextProtos，并包含"h2"和"http/1.1"：NextProtos: []string{"h2", "http/1.1"} - ✅ 如果复用已有
tls.Config，先检查并补全：if len(config.NextProtos) == 0 { config.NextProtos = []string{"h2", "http/1.1"} } - ⚠️ 不要只写
[]string{"h2"}：某些旧客户端（如部分 Android WebView）可能不支持"h2"单独存在，缺少"http/1.1"会导致握手失败 - ⚠️
MinVersion至少设为tls.VersionTLS12：HTTP/2 规范要求 TLS 1.2+，低于此版本的连接无法协商"h2"
验证 HTTP/2 是否真正生效
光看代码不能保证成功，必须实测。浏览器开发者工具的 Network 面板只显示 h2，但有时是代理或中间设备干扰；最可靠的是抓包或服务端日志。
- ✅ 服务端加日志：在 handler 中打印
r.Proto，HTTP/2 请求会输出HTTP/2.0，而非HTTP/1.1 - ✅ curl 检查：
curl -I --http2 https://localhost:8443/，成功时返回状态行带HTTP/2 200；若报HTTP/2 over cleartext is not supported，说明你误用了http:// - ⚠️ 常见假象：Nginx / Caddy 做了反向代理，它跟 Go 后端用 HTTP/1.1，但对外暴露 HTTP/2 → 此时 Go 服务本身仍是 HTTP/1.1，别被前端迷惑
- ⚠️ 浏览器地址栏显示锁图标 ≠ HTTP/2；必须进 Network → 点请求 → 查看 Protocol 列
真正容易被忽略的是：HTTP/2 的多路复用和头部压缩效果，高度依赖客户端是否真正发起多个并发请求。单个请求看不出区别，压测时若没开够并发数，也观察不到连接复用优势。不要只盯着协议名，要看实际连接数和响应延迟变化。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
