如何在 Go 中处理 HTTP2 的多路复用与头部压缩（HPACK）

Go默认启用HTTP/2，但多路复用和HPACK压缩生效需同时满足：服务端用ListenAndServeTLS配置有效TLS、客户端支持ALPN协商h2、多个请求复用同一连接；纯HTTP或未复用连接下无法体现优势。 Go 默认启用 HTTP/2，但多路复用和 HPACK 压缩是否生效，取决于客户端、服务端配置和 TLS 设置，不是写个就自动“开箱即用”。 HTTP/2 在 Go 中如何真正启用 Go 的 包从 1.6 版本起内置 HTTP/2 支持，但仅限于 TLS 场景 —— 即必须使用 或 配置了有效证书（自签名证书也行，但客户端需信任）；纯 HTTP（ ）永远走 HTTP/1.1。 常见错误现象： 显示 ，或浏览器 DevTools 的 Network 标签页里 Protocol 列显示 而非 。 确认服务端用了 ，且传入的 和 可读 客户端必须支持 ALPN（如现代 Chrome、curl ≥7.47），且 TLS 握手时协商出 ；可用 检查 ALPN 是否成功 若用自签名证书， 需加 ，但 ALPN 协商不受 影响 Go 1.19+ 默认禁用不安全的 HTTP/2 降级（如通过 ），所以不要指望非 TLS 环境下靠升级头启用 HTTP/2 多路复用在 Go 服务端无需额外编码 Go 的 对多路复用是透明支持的：只要 HTTP/2 连接建立成功，底层 会自动将每个请求映射为独立 ，并并发调用你的 。你写的 handler 完全感知不到“多路”，就像写 HTTP/1.1 一样。 但要注意真实瓶颈不在协议层： Handler 内部若用 、同步锁或阻塞 I/O（如未设 timeout 的 ），会拖慢整个连接上的所有流 —— 因为 Go 的 HTTP/2 server 是 per-connection goroutine 复用模型，不是 per-stream 独立调度 默认没有 per-stream 优先级控制；Go 不暴露 API，无法手动设置依赖或权重 若客户端并发发起 100 个请求，Go 会启动约 100 个 goroutine（每个 stream 一个），但受 和调度器影响，实际并发度可能受限 HPACK 压缩由底层库自动管理，但动态表行为可调 Go 使用 实现 HPACK，静态表（61 项）和动态表都自动维护。你不需要手动编码 header，但动态表大小会影响内存与压缩率平衡。 关键控制点在 的 和 ： 限制单个请求 header 解码后总字节数（含解压后），超限返回 可通过 设置 ，例如 控制动态表最大字节容量（默认 4096）；设太小导致重复 header 无法命中动态表，压缩率下降；设太大可能被恶意请求耗尽内存 动态表是 per-connection 的，且 request 和 response 表分离；同一个连接上，连续请求的相同 header（如 ）大概率能复用索引 注意：Go 不允许禁用 HPACK（不像某些 C 实现可关压缩），header 总是经过 HPACK 编码传输 调试与验证 HTTP/2 行为的实用手段 光看响应状态码不够，得确认帧层面是否真走 HTTP/2： 用 ，观察输出中是否有 和 浏览器 DevTools → Network → 右键表头 → 勾选 “Protocol”，列中显示 才算成功 抓包用 Wireshark，过滤 ，看是否有 、 、 帧；HPACK 解码需开启 解析偏好 服务端加日志：在 handler 里打印 ，HTTP/2 下值为 ；但注意这仅反映请求版本，不保证底层复用或压缩生效 最易被忽略的一点：HTTP/2 的多路复用和 HPACK 效果，只有在**多个请求共享同一 TCP 连接**时才体现价值。单次请求看不出区别，压测时要用支持连接复用的客户端（如 ），否则全是短连接，退化成 HTTP/1.1 行为。