通过合理配置http连接池、启用keep-alive、设置超时与上下文控制、避免goroutine泄漏，并在必要时绕过内核协议栈，可稳定支撑10k+并发连接及数万qps。
Go 处理大规模并发请求时，网络协议栈本身不需“优化”——net 包底层已深度绑定 epoll/kqueue/iocp，运行时调度器也早已消除早期 STW 和调度延迟问题。真正要调的，是**你用协议栈的方式**：连接管理、上下文控制、IO 模式、以及是否绕过内核协议栈。下面几个点，直接决定你能不能稳住 10k+ 并发连接或每秒数万请求。
为什么 http.DefaultClient 在高并发下会崩
它默认用 http.Transport，但所有参数都是零值：空闲连接池为 0、无连接复用、无超时限制。每发一次 http.Get 就新建 TCP 连接，很快打满本地端口（65535 个）或触发 too many open files 错误。
-
MaxIdleConnsPerHost必须显式设为 ≥ 20（常见值），否则每个域名只允许 2 个空闲连接 -
IdleConnTimeout建议设为 30–90 秒；太短导致频繁重连，太长则空闲连接堆积 - 不要复用
http.DefaultClient，每次 new&http.Client{Transport: tr}，避免跨业务污染配置
用 Keep-Alive 连接池时，MaxConnsPerHost 和 MaxIdleConnsPerHost 的区别
前者是硬上限（活跃 + 空闲总和），后者只是“空闲中可保留多少”。比如设 MaxConnsPerHost=30、MaxIdleConnsPerHost=20，意味着最多同时发起 30 个请求到同一 host，其中最多 20 个可挂起等待复用；一旦第 31 个请求进来，就只能等或被拒绝（取决于是否启用队列）。
- 若下游服务有连接数限制（如 Nginx 默认
max_connections为 1024），MaxConnsPerHost应 ≤ 其 80% - 若请求间隔长（如 IoT 心跳），适当提高
IdleConnTimeout，但必须配合服务端keepalive_timeout设置 - 注意：
MaxIdleConns是全局总空闲数，别设得比MaxIdleConnsPerHost × host 数小，否则会截断
什么时候该考虑绕过内核协议栈（如用 KCP/QUIC）
标准 net.Conn 走 TCP/IP 协议栈，在公网弱网、高丢包、高 RTT 场景下，TCP 的重传与拥塞控制会拖慢吞吐。rpcx、quic-go 等库提供的用户态协议栈能跳过内核，自己做流控、加密、重传。
- 用
quic-go替换 HTTP/1.1 → HTTP/3，适合移动端或 CDN 边缘节点通信 - 用
kcp-go做游戏/音视频信令通道，容忍丢包但要求低延迟，SetStreamMode(true)开启流模式后行为接近 TCP - 注意：KCP/QUIC 不是银弹——它们增加 CPU 开销、调试难度大、且服务端支持度远不如 TCP
goroutine 泄漏比性能差更致命
一个没加 context.WithTimeout 或没关 resp.Body 的 http.Client.Do，可能让 goroutine 卡在 read 系统调用上数分钟，最终积压成千上万个僵尸 goroutine，吃光内存。
- 所有
http.Client.Do必须传入带超时的context.Context，哪怕只是context.WithTimeout(ctx, 5*time.Second) -
resp.Body必须defer resp.Body.Close()，否则连接无法归还连接池 - 用
go tool trace抓取运行时 trace，搜索 “block” 或 “GC” 可快速定位卡住的 goroutine
最常被忽略的不是并发数，而是连接生命周期管理：从 dial 开始到 body 关闭结束，每个环节都可能成为瓶颈。别迷信“Goroutine 轻量”，失控的轻量加起来就是重量级事故。
