Go原生支持HTTP/2（自1.6起），但不支持HTTP/3；启用HTTP/2必须使用TLS，调用ListenAndServeTLS或配置TLSConfig即可自动协商，无需手动设置NextProtos；HTTP/2 Server Push已弃用且未实现，推荐用Link头preload替代。
Go 原生支持 HTTP/2，但不支持 HTTP/3 —— 标准库至今（2026 年 4 月）没有 HTTP/3 实现，所有“Go 支持 HTTP/3”的说法都依赖第三方库或外部代理。
Go 怎么启用 HTTP/2（必须用 TLS）
HTTP/2 在 Go 中是自动启用的，但前提是：必须走 HTTPS，且 http.Server 使用了 TLS 配置。纯 http.ListenAndServe 永远只能是 HTTP/1.1。
常见错误是以为加个 NextProtos: []string{"h2"} 就能强制启用——其实从 Go 1.8 起，只要调用 ListenAndServeTLS 或设置了 TLSConfig，标准库就会自动协商 h2，无需手动配置 NextProtos（它只是 ALPN 协商的一部分，Go 默认已包含）。
- 正确启动方式：
http.ListenAndServeTLS(":443", "cert.pem", "key.pem") - 自定义
http.Server时，确保设置了TLSConfig，哪怕为空结构体：&http.Server{Addr: ":443", TLSConfig: &tls.Config{}} - 开发用自签名证书？用
generate_cert.go生成，但浏览器会报x509: certificate signed by unknown authority；客户端测试时需传&http.Client{Transport: &http.Transport{TLSClientConfig: &tls.Config{InsecureSkipVerify: true}}} - 别在 Nginx 后面盲目配 Go 的 HTTP/2：Nginx 默认终止 TLS 后以 HTTP/1.1 转发，后端 Go 服务看到的仍是
r.Proto == "HTTP/1.1"；要透传 HTTP/2，得用 Nginx 的proxy_http_version 2+proxy_ssl_protocols TLSv1.2 TLSv1.3等严格配置
怎么确认 Go 服务真在跑 HTTP/2
不能看代码有没有写 h2，也不能信日志里“started HTTPS server”——得看实际连接协商结果。
立即学习“go语言免费学习笔记（深入）”；
Chrome DevTools 是最直接的方式：打开 Network 面板，右键表头勾选 Protocol 列，刷新页面，主文档行显示 h2 才算成功。注意：子资源（如 JS、CSS）可能因缓存、跨域或 CDN 降级而显示 http/1.1，只看主响应即可。
命令行验证用 curl -v --http2 https://localhost:443，关键观察点：
- 输出中出现
ALPN, offering h2和SSL connection using TLSv1.3 / ECDHE - 响应头里有
HTTP/2 200（不是HTTP/1.1 200） - 没有
Failed to negotiate ALPN或Unsupported protocol类错误
服务端也可加简单判断：if r.Proto == "HTTP/2.0" { log.Println("got HTTP/2 request") } —— 注意是 HTTP/2.0，不是 HTTP/2。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
Go 为什么没有原生 HTTP/3 支持
HTTP/3 底层依赖 QUIC 协议，而 QUIC 是一个复杂、仍在演进的传输层协议，涉及加密、丢包恢复、连接迁移等大量状态管理。Go 标准库的 net/http 设计基于 TCP 抽象，无法直接嫁接 QUIC；且官方明确表示暂无计划将 QUIC 纳入标准库（截至 Go 1.23，2026 年初）。
目前可行路径只有两条：
- 用第三方库如
quic-go+ 自实现 HTTP/3 服务器（例如lucas-clemente/quic-go/http3），但这类实现不兼容标准http.Handler接口，需重写路由和中间件逻辑 - 用反向代理方案：Caddy 或 nginx-quic（Nginx 官方 QUIC 分支）做前端 terminating HTTP/3，后端仍用 Go 的 HTTP/2 或 HTTP/1.1 —— 这是生产环境唯一稳定选择
注意：quic-go 虽成熟，但它不是标准库，版本升级常打破 API；且 Go 的 http.Transport 完全不识别 https:// URL 的 QUIC 后端，http.Get("https://...") 永远走 TLS/TCP，不会自动切到 QUIC。
HTTP/2 Server Push 为什么基本不用
Go 标准库的 http.Pusher 接口自存在起就不可用：调用 w.(http.Pusher).Push() 在所有 Go 版本（1.8–1.23）中都会 panic 或静默失败。这不是配置遗漏，而是标准库压根没实现推送逻辑。
官方早已放弃 Server Push，原因很实在：
- 现代浏览器（Chrome 96+、Firefox 90+）已禁用或弱化 Push 行为
- Push 容易造成队头阻塞、浪费带宽、干扰缓存策略
- 等效替代方案更轻量可控：
w.Header().Set("Link", `<style.css>; rel=preload; as=style`)
这个 Link 头在 HTTP/1.1 和 HTTP/2 下都生效，且由浏览器自主决定是否预加载，不占用服务端连接资源。真正要注意的是：它必须在 WriteHeader 前设置，路径必须是绝对路径（/assets/main.js）或以 / 开头的相对路径，不能是完整 URL（https://...）。
别被网上“Go HTTP/3 库”或“Patch http2 包启用 Push”的教程误导——那些代码要么编译不过，要么在 Go 1.22+ 上触发 connection error: PROTOCOL_ERROR，或者随一次标准库升级彻底失效。
