http.DefaultClient 默认无超时，卡死因 Dial 阶段未设 net.Dialer.Timeout；需分阶段配置 DialContext、TLSHandshakeTimeout、ResponseHeaderTimeout 等，避免粗粒度 Client.Timeout 覆盖。
为什么 http.DefaultClient 会卡死，而不是超时？
因为 Go 标准库的 http.DefaultClient 和所有未显式配置的 *http.Client 实例，**默认没有任何超时控制**。这不是疏忽，而是设计上要求你为每个业务场景明确声明“我愿意等多久”。一旦遇到 DNS 解析失败、SYN 包丢弃、服务端不响应 SYN-ACK 或 TLS 握手卡住，client.Do() 就可能阻塞数分钟甚至更久——尤其在 Linux 上受 tcp_syn_retries 内核参数影响。
- 现象：程序看起来“假死”，
pprof显示 goroutine 停在net.(*pollDesc).wait或runtime.gopark - 根本原因：底层
net.Dialer的Timeout字段为零值，触发系统默认重试策略 - 错误认知：“我设了
conn.SetReadDeadline()，应该不会卡”——但它对Dial阶段完全无效
net.Dialer.Timeout 是 TCP 连接超时的唯一可靠入口
要真正解决“连不上”的问题，必须从连接建立阶段下手，而 net.Dialer.Timeout 就是这个阶段的开关。它控制的是从调用 DialContext 开始，到 TCP 三次握手完成（收到 SYN-ACK + 发送 ACK）的**绝对耗时上限**，和读写无关。
-
net.DialTimeout已被标记为 deprecated（Go 1.17+），必须改用&net.Dialer{Timeout: 5 * time.Second} - 推荐值：3–5 秒。太短易误杀（如跨公网首次建连），太长失去保护意义
- 注意：该超时只影响
DialContext，不影响后续Write/Read；读写超时需单独用SetReadDeadline或ResponseHeaderTimeout - 示例：
dialer := &net.Dialer{Timeout: 4 * time.Second, KeepAlive: 30 * time.Second} conn, err := dialer.Dial("tcp", "192.168.0.1:8080")
HTTP 客户端超时不能只靠 Client.Timeout
http.Client{Timeout: 10 * time.Second} 看似简单，但它是一个“总闸”，会粗暴覆盖所有子阶段（DNS、Dial、TLS、写请求、读 header、读 body）。一旦设置过短，可能把本应成功的慢响应也干掉；设得太长，又起不到保护作用。生产环境更推荐分阶段控制。
-
Transport.DialContext：必须用自定义net.Dialer，否则无法限制连接建立 -
Transport.TLSHandshakeTimeout：HTTPS 必设，避免 TLS 协商卡住（如服务端不支持客户端 cipher suite） -
Transport.ResponseHeaderTimeout：最关键的分界点——它只管“从发完请求到收到 status line + headers”，不包含 body 读取。适合判断服务是否“活着” - 陷阱：
Client.Timeout会覆盖Transport所有子超时，所以建议设为略大于各阶段之和，或干脆不设，全由Transport控制
怎么判断真是超时，而不是其他网络错误？
别用 strings.Contains(err.Error(), "timeout") —— 不跨平台、不可靠、易漏判。Go 的标准错误体系提供了稳定接口：net.Error。
立即学习“go语言免费学习笔记（深入）”；
- 正确方式：类型断言 + 方法调用：
if netErr, ok := err.(net.Error); ok && netErr.Timeout() { /* 这才是超时 */ } -
netErr.Timeout()返回 true：涵盖Dial、Read、Write、TLS handshake等所有系统级等待超时 -
netErr.Temporary()返回 true：表示可重试（如ECONNREFUSED、ENETUNREACH），但要注意——不是所有Temporary()都该重试，比如 DNS 解析失败（dns.ErrNoAnswer）可能意味着配置错误 - HTTP 层额外注意：
context.DeadlineExceeded是 context 超时，优先用errors.Is(err, context.DeadlineExceeded)判断，它比net.Error更上层、更语义化
真正难的不是设几个 time.Second，而是理解每个超时字段作用在哪一毫秒——连接建立、TLS 握手、首字节响应、完整响应体，它们发生在不同 goroutine、不同系统调用里。漏掉任意一环，就可能让服务在某个角落悄悄卡住。
