是，go 1.8+ 启动 https 服务（如用 http.listenandservetls 或配置 tlsconfig）即自动启用 http/2，无需额外导入或调用配置函数；纯 http 则永远为 http/1.1。

Go 启动 HTTPS 服务就自动启用 HTTP/2

只要用 http.ListenAndServeTLS 或配置了 TLSConfig 的 http.Server，Go 1.8+ 就会自动协商 HTTP/2 —— 不需要 import golang.org/x/net/http2，也不用调 http2.ConfigureServer。这是默认行为，不是可选功能。

常见错误是手动往 TLSConfig.NextProtos 里塞 ["h2"]，其实多余；Go 已内置 ALPN 协商支持，加了反而可能干扰默认逻辑。

• 正确做法：直接调 http.ListenAndServeTLS(":443", "cert.pem", "key.pem")
• 自定义 server 时，哪怕 TLSConfig 是空结构体也要显式设置：&http.Server{Addr: ":443", TLSConfig: &tls.Config{}}
• 纯 http.ListenAndServe 永远走 HTTP/1.1，HTTP/2 不支持明文

确认 HTTP/2 真正在跑，别信日志信连接

代码里写了 TLS ≠ 实际用了 HTTP/2。浏览器 DevTools 的 Protocol 列才是黄金标准：Network 面板右键表头勾选 Protocol，主 HTML 响应行显示 h2 才算成功。

curl 命令验证更底层：curl -v --http2 https://localhost:443，重点看三处：

• 输出里有 ALPN, offering h2 和 SSL connection using TLSv1.3
• 响应行是 HTTP/2 200，不是 HTTP/1.1 200
• 没有 Failed to negotiate ALPN 类报错

服务端也可加判断：if r.Proto == "HTTP/2.0"（注意是 HTTP/2.0，不是 HTTP/2）

反向代理后端必须透传 TLS，否则 HTTP/2 降级

Nginx / Caddy 作为前置代理时，如果只做 TLS 终止再以 HTTP/1.1 转发，Go 后端看到的仍是 r.Proto == "HTTP/1.1"，HTTP/2 彻底失效。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

要透传 HTTP/2，Nginx 必须开启 HTTP/2 代理并严格配置：

• proxy_http_version 2.0
• proxy_ssl_protocols TLSv1.2 TLSv1.3
• proxy_ssl_server_name on

Caddy 默认支持，但需确保 upstream 地址带 https:// 前缀，且证书可信（或配置 insecure_skip_verify）

Server Push 已弃用，用 Link 头替代

Go 1.23 起 http.Pusher 接口被移除，所有基于它的 Server Push 代码会编译失败。这不是 bug，是明确弃用。

现代替代方案是响应头 Link 预加载：

w.Header().Set("Link", `<style.css>; rel=preload; as=style`, `<app.js>; rel=preload; as=script`)
</app.js></style.css>

注意点：

• 只对未缓存资源有效，已缓存的浏览器会忽略
• 推送体积建议 ≤100KB，过大反而拖慢主文档渲染
• 优先级靠浏览器自主调度，不保证执行顺序

真正容易被忽略的是：HTTP/2 性能提升高度依赖 TLS 握手速度和 TCP 连接复用。用自签名证书测试时，InsecureSkipVerify: true 只解决信任问题，不解决握手延迟——生产环境务必用有效证书 + OCSP stapling + TLS 1.3。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！