17370845950

根本原因是底层 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 每次调用都重置，天然适配多次读

哪些库默认不设超时，最容易引发线上阻塞？

以下常见库/用法默认无超时，上线前务必检查：

• 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，导致超时错误被忽略，gorout