Gin本身不配置多路复用，因为它不参与连接层I/O多路复用，该功能由Go runtime底层（epoll/kqueue/IOCP）自动实现；真正的调优点在于http.Server和http.Transport的超时设置、连接池参数及避免阻塞handler等细节。
为什么Gin本身不配置多路复用
Gin 没有“多路复用配置项”——它根本不参与连接层的 I/O 多路复用。Gin 只是基于 net/http 的封装，而真正的多路复用由 Go runtime 底层完成：http.Server 启动后，runtime 自动绑定 epoll（Linux）、kqueue（macOS）或 IOCP（Windows），监听 socket 事件并唤醒 goroutine。你调用 r.Run() 或 http.ListenAndServe() 时，这个机制已默认启用，无需额外开关。
高带宽场景下真正要调的是 http.Server 和 Transport
带宽上不去、延迟抖动大，问题通常不在 Gin 路由层，而在连接生命周期和 I/O 调度细节。重点调整以下三项：
-
http.Server.ReadTimeout和WriteTimeout：避免慢请求长期占用连接，尤其在千兆以上网络中，TCP 窗口可能撑满但应用未及时读写，导致连接假性卡死 -
http.Server.IdleTimeout：必须显式设置（如30 * time.Second），否则默认 0（永不超时），高并发长连接下易积累大量 idle 连接，耗尽文件描述符 -
http.Transport的MaxIdleConns/MaxIdleConnsPerHost：若 Gin 服务作为 HTTP 客户端（比如调用下游 API），这些参数决定复用连接池大小；设太小会频繁建连，设太大则可能触发对方限流
别踩这些 Gin 相关的坑
看似和“多路复用”有关，实则破坏并发效果：
- 在 handler 里直接用
http.DefaultClient：它底层的http.Transport是单例且不可配置，MaxIdleConns默认仅 100，高带宽下极易成为瓶颈 - 忘记关闭响应体：
resp.Body.Close()缺失 → 连接无法归还池 →IdleConn数持续下降 → 新请求被迫新建连接 - 全局共享未配置连接池的
*sql.DB：即使 Gin 并发处理请求，DB 连接争抢会把并发变成串行，日志里看到的“延迟叠加”其实是锁等待，不是网络问题 - 用
time.Sleep或同步 I/O（如无 context 控制的io.ReadAll）阻塞 handler：goroutine 被挂起，虽不阻塞其他请求，但会拖慢该连接上的后续 pipelined 请求（HTTP/1.1）
验证是否真正在用多路复用
光看 QPS 不够，得确认底层确实在事件驱动模式下工作：
立即学习“go语言免费学习笔记（深入）”；
- 查进程 fd 数：
lsof -p $(pidof your-bin) | wc -l，稳定在几千以内说明连接复用正常；若随并发线性增长，大概率是连接没复用 - 抓包看 TCP 行为：用
tcpdump观察是否大量出现SYN→FIN往返，而非复用同一连接发送多个 request - 监控
http.Server的ConnState回调：记录StateNew和StateClosed比例，理想情况下前者远少于后者
高带宽环境里，连接复用效率比单请求吞吐量更关键——一个 10Gbps 网卡跑不满，往往是因为每秒建了上千连接，而不是因为 goroutine 调度不够快。
