Goroutine本身不实现多路复用，它只是轻量级并发单元；多路复用特指单连接承载多个逻辑请求流，由协议栈（如HTTP/2）或客户端库（如http.Transport）实现，goroutine仅提供并发执行基础。
goroutine 本身不实现多路复用，它只是轻量级并发单元
Go 的 goroutine 本身不是多路复用机制，它不负责 I/O 调度或连接复用。真正实现网络请求多路复用（如 HTTP/2 复用 TCP 连接、单连接并发发多个请求）的是底层协议栈和客户端库，goroutine 只是让你能“自然地”并发发起多个请求而不阻塞主线程。
常见误解是以为开一堆 goroutine 就等于“多路复用”，其实那是并发（concurrency），不是复用（multiplexing）。多路复用特指：单个连接承载多个逻辑请求流（如 HTTP/2 stream、gRPC channel、WebSocket 子信道）。
HTTP/1.1 默认不复用，需手动复用 http.Transport
Go 标准库的 http.Client 默认启用了连接复用（keep-alive），但前提是服务端也支持且未关闭连接。关键在 http.Transport 配置：
-
MaxIdleConns和MaxIdleConnsPerHost控制空闲连接池大小，设太小会导致频繁建连 -
IdleConnTimeout决定空闲连接多久后被回收，过短会破坏复用效果 - 默认
http.DefaultClient已开启复用，但生产环境建议显式配置，避免隐式行为差异
示例：
立即学习“go语言免费学习笔记（深入）”；
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
},
}HTTP/2 自动启用多路复用，但需服务端协商支持
只要 Go 版本 ≥ 1.6，且服务端返回 h2 ALPN 协议（如 Nginx/OpenResty 启用 http2、TLS 配置正确），http.Client 会自动升级到 HTTP/2 —— 此时单个 TCP 连接可并行处理多个请求（每个请求一个 stream），无需额外代码。
验证是否走 HTTP/2：
- 检查响应的
resp.Proto是否为"HTTP/2.0" - 用
curl -v --http2 https://example.com看是否显示ALPN, offering h2 - 注意：HTTP/2 仅支持 TLS（即 HTTPS），明文 HTTP/2（h2c）需显式启用且极少被服务端支持
手动实现连接层多路复用（如自定义协议）要用 net.Conn + sync.Pool + 分帧
如果你在写 RPC 或私有协议客户端，想在一个 TCP 连接上并发收发多个请求/响应，就得自己做分帧、stream ID 管理和响应匹配。这时 goroutine 是配合角色，不是解决方案本身：
- 每个请求分配唯一
streamID，写入时带上该 ID - 启动一个读 goroutine 持续解析响应帧，并根据
streamID分发给对应等待的 goroutine（常用map[uint32]chan<Response>+sync.RWMutex） - 用
sync.Pool复用帧缓冲区，避免高频小对象 GC - 务必设置读写超时（
conn.SetDeadline），否则一个卡死连接会让所有 stream 阻塞
这种模式在 gRPC-Go 底层、TiDB 的 client 实现中都能看到影子，但业务层极少需要重造。
最容易被忽略的一点：多路复用的价值只有在高延迟或连接建立成本高（如 TLS 握手）时才显著。本地开发用 localhost 测试 HTTP/1.1 复用效果往往不明显，因为建连极快；真要验证，得压测跨公网、带 TLS 的场景。
