quic-go v0.46.0是go生态唯一稳定落地http/3的方案，因官方net/http至今不支持http/3服务端；不能用http.listenandservetls，因其基于tcp且无法触发quic连接流程，必须改用quic.listenaddr或http3.server，并显式配置tlsconfig.nextprotos=["h3"]、quicconfig.maxincomingstreams≥1000等关键参数。
直接用 quic-go v0.46.0 是目前 Go 生态中唯一能稳定落地的方案，官方 net/http 仍不支持 HTTP/3 服务端，强行自研 UDP+TLS 层会踩进拥塞控制、丢包恢复、流状态同步等深坑。
为什么不能直接套用 http.ListenAndServeTLS
QUIC 协议强制要求 TLS 1.3 + ALPN 协商，而 http.ListenAndServeTLS 底层走的是 TCP，它根本不会触发 QUIC 的连接建立流程。你看到服务“启动成功”，但客户端发起 https:// 请求时，实际走的仍是 HTTP/1.1 或 HTTP/2，完全没进 QUIC 栈。
- 典型错误现象：
http: server closed idle connection或客户端静默降级到 HTTP/2，Wireshark 抓不到 QUIC 包 - 必须改用
quic.ListenAddr（裸 QUIC）或http3.Server（HTTP/3 封装） -
http3.Server不自动读取http.DefaultServeMux，Handler字段必须显式赋值
http3.Server 启动失败的三个高频漏点
很多开发者照着示例写完就 panic，问题往往出在初始化阶段的隐式依赖上。
-
TLSConfig.NextProtos必须包含"h3"，漏掉就会报no application protocol negotiated -
QUICConfig.MaxIncomingStreams默认是 100，压测时新流被拒绝，建议设为1000或更高 - 没给
http3.Server.Addr绑定有效端口（如":443"），或端口被占用却没看日志里的listen tcp :443: bind: permission denied
证书和 ALPN 配置必须同时生效
自签名证书在开发阶段够用，但 tls.Config 构造时容易忽略两个关键点：一是必须用 TLS 1.3，二是必须显式开启 ALPN。
- Go 1.22+ 默认启用 TLS 1.3，但若手动指定
MinVersion低于tls.VersionTLS13，QUIC 会直接拒绝连接 -
NextProtos: []string{"h3"}是硬性要求，h3-29等旧版本已废弃，v0.46.0 只认"h3" - 生成自签名证书时，
ExtKeyUsage必须含x509.ExtKeyUsageServerAuth，否则 TLS 握手失败
客户端如何确保真正走 QUIC 而非静默降级
Go 的 http.DefaultClient 完全无视 HTTP/3，必须彻底替换底层传输层。
- 必须用
http3.RoundTripper，且初始化时传入带NextProtos: []string{"h3"}的*tls.Config - URL 必须以
https://开头，且服务端需响应Alt-Svc: h3=":443"头，否则客户端不会尝试 H3 - 某些代理或 CDN 会剥离
Alt-Svc头，此时需用http3.WithDialer强制直连 QUIC 端口
最易被忽略的是流控与连接生命周期管理：http3.Server 不提供连接空闲超时、最大连接数等常见 HTTP/1.x 参数，这些得靠 quic.Config 中的 MaxIdleTimeout、KeepAlivePeriod 手动控制；另外，QPACK 编解码器流（ID 2 和 3）一旦创建失败，整个连接会立即关闭，但错误日志里只显示 stream creation error，需结合 Wireshark 抓包确认是否因重复建流触发了 ErrCodeStreamCreationError。
