根本原因是底层 socket 无数据且未设超时；需检查 SetReadDeadline、对端发包、bufio 缓冲及 http.Client 的 Dial/ TLS/ Header 三重超时设置。
为什么 net.Conn.Read 会卡住不返回？
根本原因不是 Go 本身阻塞，而是底层 socket 没有数据可读且未设置超时。Go 的 net.Conn 默认是阻塞 I/O，Read 会一直等，直到对端发来数据、关闭连接，或者发生错误（比如网络中断）。常见于客户端等待服务端响应、长连接心跳场景。
- 检查是否漏掉了
SetReadDeadline或SetReadTimeout—— 这是最常见的疏忽 - 确认对端是否真的发送了数据（用
tcpdump或Wireshark抓包验证） - 注意：即使对端
close()，Linux TCP 栈也可能延迟发送 FIN，导致Read等待数秒才返回io.EOF - 若使用
bufio.Reader，它内部缓冲可能导致“看似卡住”——实际是没填满缓冲区，不会触发底层Read调用
如何给 http.Client 设置全局超时？
http.Client 的超时不是单个字段能控制的，必须组合设置三个时间点，否则仍可能阻塞：
client := &http.Client{
Timeout: 10 * time.Second, // 仅作用于整个请求（从 Dial 到响应 body 读完）
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second, // 建连超时
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 5 * time.Second, // TLS 握手超时
ResponseHeaderTimeout: 5 * time.Second, // 从写完 request 到收到 header 的最大耗时
ExpectContinueTimeout: 1 * time.Second, // expect 100-continue 的等待上限
},
}-
Timeout是兜底项，但无法覆盖 DNS 解析、TLS 握手等中间环节 - 如果服务端只写 header 不写 body，
ResponseHeaderTimeout才能及时中断；否则Timeout要等到整个响应体读完才生效 - 不要依赖
DefaultClient，它的超时是 0（无限等待）
select + time.After 能替代 SetReadDeadline 吗？
不能直接替代，尤其在复用连接（如 HTTP/1.1 keep-alive）或需要精确控制每个读操作时。两者语义不同：
-
SetReadDeadline是 socket 级别设置，内核在超时后直接返回syscall.EAGAIN，Go runtime 将其转为net.OpError，干净可靠 -
select+time.After是 goroutine 级别协作，依赖调度器唤醒，实际超时可能比设定值多几毫秒甚至几十毫秒；更严重的是，它无法取消正在执行的系统调用，只是让 goroutine 放弃等待，而底层read()仍在内核中阻塞（直到超时或数据到达） - 若连接被复用，
time.After触发后未关闭连接，下次读仍可能卡住；而SetReadDeadline每次调用都重置，天然适配多次读
哪些库默认不设超时，最容易引发线上阻塞？
以下常见库/用法默认无超时，上线前务必检查：
立即学习“go语言免费学习笔记（深入）”；
-
database/sql：驱动层（如mysql、pgx）的Query/Exec默认不设网络超时，需显式传context.WithTimeout -
redis/go-redis：client.Get(ctx, key)中的ctx若是context.Background()，则永不超时 -
grpc-go：client.Call若未传带 timeout 的 context，将无限等待 - 自定义
net.Conn实现（如 TLSConn、自定义封装）：容易忘记透传或重置 deadline
最隐蔽的坑是：超时设置对了，但错误处理里没检查 errors.Is(err, context.DeadlineExceeded) 或 net.ErrTimeout，导致超时错误被忽略，goroutine 泄露持续累积。
