Go标准库不支持HTTP/3，必须使用quic-go/http3库，且服务端与客户端配置须独立、完整匹配，任一端缺失或错配将静默降级至HTTP/1.1；服务端需监听UDP端口、TLSConfig中NextProtos含"h3"、QUICConfig调大MaxIncomingStreams，客户端须用http3.RoundTripper并配置相同TLS参数，验证需通过Chrome协议列、curl ALPN或Wireshark确认。
Go 标准库不支持 HTTP/3，必须用 quic-go/http3 库，且服务端和客户端配置完全独立、互不兼容 —— 任一端缺失或错配，连接就会静默降级到 HTTP/1.1。
启动 HTTP/3 服务端：别漏掉 UDP 端口和 QUIC 配置
HTTP/3 基于 QUIC，而 QUIC 是 UDP 协议，http3.Server 默认监听 UDP 端口（不是 TCP），所以不能复用 http.ListenAndServeTLS 的写法。
-
http3.Server必须显式设置Addr（如":443"），它会同时尝试绑定 TCP 和 UDP；但真正承载 HTTP/3 流量的是 UDP 套接字 -
TLSConfig.NextProtos必须包含"h3"，否则 ALPN 协商失败，浏览器或客户端不会尝试 HTTP/3 -
QUICConfig要调大MaxIncomingStreams（默认 100），否则高并发下新流被拒绝，表现为请求超时而非报错 - 证书必须有效；自签名证书在浏览器中会触发安全警告，但
curl --http3或 Go 客户端可加TLSClientConfig.InsecureSkipVerify = true绕过
最小可行服务端：
server := &http3.Server{
Addr: ":443",
Handler: myMux,
TLSConfig: &tls.Config{
NextProtos: []string{"h3"},
Certificates: []tls.Certificate{cert},
},
QUICConfig: &quic.Config{
MaxIncomingStreams: 1000,
},
}
log.Fatal(server.ListenAndServe())
Go 客户端发起 HTTP/3 请求：不能用 http.DefaultClient
Go 的 net/http 客户端默认完全忽略 HTTP/3 —— 即使服务端已就绪，http.Get 或 http.DefaultClient.Do 也只会走 HTTP/1.1 或 HTTP/2。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须使用
http3.RoundTripper替换Transport，且需传入带NextProtos: []string{"h3"}的tls.Config - 若
http3.RoundTripper初始化时未传tls.Config，它会 fallback 到 HTTP/1.1 且不报错，现象是“请求成功但没走 QUIC” - 不能复用
http.DefaultClient，必须新建*http.Client并指定Transport - 若服务端用自签名证书，客户端
tls.Config必须设InsecureSkipVerify: true，否则 TLS 握手失败
正确客户端示例：
client := &http.Client{
Transport: &http3.RoundTripper{
TLSClientConfig: &tls.Config{
NextProtos: []string{"h3"},
InsecureSkipVerify: true,
},
},
}
resp, err := client.Get("https://example.com/")
验证是否真走 HTTP/3：看协议字段，别信日志或代码注释
服务端日志里出现 ALPN, offering h3 或客户端打印 using quic-go 不代表实际用了 HTTP/3；真正生效必须满足两端协商成功。
- Chrome DevTools → Network 面板 → 右键表头勾选
Protocol列 → 刷新页面 → 主文档行显示h3才算成功 - 服务端可在 handler 里检查：
r.Proto == "HTTP/3"（注意是HTTP/3，不是HTTP/3.0或其他） - 用
curl -v --http3 https://example.com/ 2>&1 | grep ALPN，看到ALPN, server accepted to use h3才确认协商完成 - Wireshark 抓包看 UDP 流是否含 QUIC 帧（端口通常为 443，协议识别为
quic）
HTTP/2 和 HTTP/3 共存时的常见陷阱
同一个 HTTPS 端口上同时支持 HTTP/2 和 HTTP/3 是可行的，但容易因配置重叠引发降级或冲突。
-
TLSConfig.NextProtos必须同时包含"h2"和"h3"，顺序无关，ALPN 协商由客户端决定优先级 - Nginx 或其他反向代理若插在中间，会终止 QUIC；HTTP/3 必须直连 Go 服务端，不能经由只支持 TCP 的代理
- 某些 CDN（如 Cloudflare）支持 HTTP/3 回源，但要求源站明确监听 UDP 且防火墙放行，否则客户端看到
ERR_HTTP2_PROTOCOL_ERROR类错误 - Go 服务端启用 HTTP/2 不需要手动配
NextProtos，但 HTTP/3 必须显式声明；混用时别误删"h3"
最易被忽略的点：UDP 端口被防火墙拦截、云服务器安全组未开放 UDP 443、客户端操作系统禁用 QUIC（如旧版 Windows 或企业策略限制）、以及 quic-go 版本与 Go 版本不匹配导致编译失败或运行时 panic —— 这些问题都不会抛出明确错误，只会静默回退。
