Golang网络请求慢怎么排查优化

HTTP客户端未设超时会导致goroutine永久卡在net.Conn.Read；必须手动配置DialContext.Timeout、TLSHandshakeTimeout和ResponseHeaderTimeout三重超时，且需为每次读操作设置SetReadDeadline。

HTTP客户端没设超时，请求就卡死在内核里

Go 的 http.DefaultClient 所有超时都是 0，意味着 DNS 解析、建连、TLS 握手、等响应头、读响应体……任何一个环节 hang 住，goroutine 就永远卡在 net.Conn.Read 上，不报错也不返回。这不是代码写错了，是默认行为如此。

必须手动组合三重超时：

• DialContext.Timeout：控制建连（含 DNS 查询）耗时
• TLSHandshakeTimeout：专管 TLS 握手，HTTPS 场景下极易超时
• ResponseHeaderTimeout：从 request 发完到收到第一个字节 header 的最大等待时间——这是最常被漏掉、也最能“快速止损”的一环

别只设 Timeout 字段，它只覆盖整个请求生命周期，对中间卡点无效；更别复用未配置的全局 client，高并发下会因 MaxIdleConnsPerHost 不足而排队等连接。

Read 操作卡住却不报错？先看有没有 SetReadDeadline

底层 socket 没数据可读 + 没设 deadline = 无限等待。这不是 Go 的 bug，是 POSIX socket 的默认语义。你看到的“卡住”，大概率是对方还没发、或发得慢、或 TCP 窗口被堵死了。

排查步骤很直接：

• 确认代码中是否对每个 net.Conn 或 bufio.Reader 调用了 SetReadDeadline（注意：每次读前都得重置）
• 用 ss -i 查 Recv-Q 是否持续非零，若堆积说明应用层没及时读，缓冲区满了
• 抓包验证对端是否真发了数据——别靠猜，tcpdump -i any port 8080 两分钟就能定性

别用 select + time.After 替代 SetReadDeadline，前者无法取消系统调用，连接复用时隐患极大。

goroutine 堆积不是 CPU 高，而是 channel 或 DB/HTTP 调用没兜底

响应变慢，90% 的情况不是 CPU 爆了，而是 goroutine 在等 channel 接收、等数据库行锁、等下游 HTTP 返回。它们安静地躺在 select 或 chan receive 状态，不占 CPU 却吃内存、压垮连接池。

立刻做三件事：

• 访问 /debug/pprof/goroutine?debug=2，搜 database/sql.(*DB).QueryRow 或 http.(*Client).Do，看是不是一堆 goroutine 卡在同一个调用点
• 检查所有 http.Client 是否设置了 Transport.MaxIdleConnsPerHost，默认是 2，QPS 一高就排队
• 查 channel 使用：发送方已退出但接收方还在等？或者 select 中没写 default 分支导致永久阻塞？

runtime.SetMutexProfileFraction(1) 后再看 /debug/pprof/mutex，能快速定位锁竞争热点，比如日志写入或配置热更新时的争用。

中间件和路由匹配本身就在拖慢首字节延迟

用 chi 或 gin 时，你以为性能瓶颈在业务逻辑，其实可能卡在框架内部：中间件链过长、路由通配符太宽（比如 /api/v1/*）、甚至 logger 里偷偷调了 req.Body.Read 把 body 消费光了——后续 handler 直接读不到。

实操建议：

• 写一个裸 http.HandlerFunc 绕过所有框架，测 baseline 延迟，再逐个加回中间件对比
• 避免在中间件里做同步 I/O：不要查 DB、不要读文件、尤其别解析 req.Body
• 把模糊路由改成精确前缀，静态资源走独立路径（如 /static/），减少 trie 匹配开销

真实响应时间 ≠ 日志里 time.Since() 差值，它漏掉了 TLS 握手、body 读取、header 写入等关键阶段。要用自定义 Handler + WriteHeader 打点，才看得清瓶颈在哪一层。