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 窗口被堵死了。
立即学习“go语言免费学习笔记（深入）”；
排查步骤很直接：
- 确认代码中是否对每个
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 打点，才看得清瓶颈在哪一层。
