Go不自动降低网络延迟，关键在连接复用、超时控制、并发节制和协议选型；默认http.Client配置因频繁握手、连接池未优化及缺失关键超时导致延迟飙升。
Go 本身不自动降低网络延迟，关键在连接复用、超时控制、并发节制和协议选型——不改这些，开再多 goroutine 只会让延迟更抖。
为什么 http.Client 默认配置会让延迟飙升
每次调用 http.Get() 或新建 http.Client 实例，都会触发全新 TCP 握手 + TLS 协商（HTTPS），耗时通常在 50–300ms。高并发下大量连接争抢本地端口，还会触发 connect: cannot assign requested address 错误。
-
MaxIdleConns和MaxIdleConnsPerHost默认都是 100，看似够用，但若未显式设置IdleConnTimeout，空闲连接可能长期滞留，占用端口又无法复用 -
ForceAttemptHTTP2虽默认为true，但 HTTP/2 仅在 TLS 下生效；纯 HTTP/1.1 场景下，多路复用不启用，队头阻塞照旧 - 未设
ResponseHeaderTimeout时，一个慢响应会卡住整个连接池中的某条连接，后续请求被迫排队或新建连接
必须调整的 Transport 参数组合
以下配置适用于单服务目标（如调用内部 API）、QPS 在 100–1000 区间：
tr := &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 30,
MaxConnsPerHost: 50,
IdleConnTimeout: 30 * time.Second,
DialTimeout: 3 * time.Second,
TLSHandshakeTimeout: 3 * time.Second,
ResponseHeaderTimeout: 5 * time.Second,
ExpectContinueTimeout: 1 * time.Second,
}
-
MaxIdleConnsPerHost=30是核心：它应略高于你对单个下游服务的典型并发请求数（例如压测峰值 25，则设 30） -
IdleConnTimeout=30s是平衡点：太短（如 5s）导致频繁重连；太长（如 90s）使连接池“虚胖”，端口耗尽风险上升 -
ResponseHeaderTimeout必须显式设值（建议 ≤5s）：它防止某个后端卡在写响应头阶段，拖垮整条连接
goroutine 并发数不是越多越好
盲目用 go f() 启动数百 goroutine，大概率触发本地端口耗尽（net.Dial 失败）、TCP 拥塞丢包、或下游服务被压垮——此时延迟不是变低，而是出现长尾毛刺甚至雪崩。
- 用
golang.org/x/sync/semaphore限流，例如sem := semaphore.NewWeighted(50)，每次请求前sem.Acquire(ctx, 1) - 重试只针对临时错误：
net.OpError、context.DeadlineExceeded、HTTP 状态码502/503；跳过所有4xx - 幂等接口才加指数退避；非幂等操作（如
POST /orders）应在业务层用状态机+异步补偿，而非靠 HTTP 重试掩盖问题
真正降延迟的替代方案
当 net/http 成为瓶颈，且你控制上下游协议时，可绕过 HTTP 栈：
- 对内部服务，直接用
gRPC（基于 HTTP/2 + Protocol Buffers）：序列化体积比 JSON 小 60%~80%，头部压缩 + 多路复用天然抗延迟 - 极简场景下，用
encoding/json+net.Conn直连 TCP：省掉 HTTP 解析、状态机、header 构建开销，适合固定格式的内部通信 - 不要在 hot path 上做 DNS 解析：预解析域名并缓存
net.IP，或禁用 cgo（CGO_ENABLED=0）避免getaddrinfo阻塞 M
最易被忽略的是：延迟毛刺往往不在 Go 代码里，而在 MySQL 连接池打满、Redis 阻塞命令、或容器 CPU quota 被超额分配——先确认 go tool trace 中 goroutine 是卡在 net.Read 还是 chan send，再决定优化方向。
