http.defaultclient不能用于生产环境，因其timeout为零值，无超时限制，易导致请求卡死、goroutine泄漏和连接堆积；应显式配置client.timeout与transport各阶段超时，并优先使用context.withtimeout实现可取消的跨goroutine超时控制。
http.Client 的超时设置不是“语言学习”问题，而是明确的工程实践选择：用错配置项、忽略分阶段控制、或混淆 context 与 Timeout 字段，都会导致超时失效或行为不符合预期。
为什么 http.DefaultClient 不能直接用于生产环境
它没有设置任何超时，http.Get 调用可能卡死数分钟甚至更久。常见现象是：服务 CPU 正常但 goroutine 数持续上涨，netstat 显示大量 ESTABLISHED 连接未关闭。
-
http.DefaultClient.Timeout是零值，等价于不设限 - 即使你只调一次
http.Get，也应显式构造新 client，而非复用默认实例 - Go 1.19+ 已将
http.DefaultClient标记为“不推荐用于长期运行服务”
http.Client.Timeout 和 http.Transport 超时的区别
Timeout 是“总耗时兜底”，而 Transport 配置能拆解每个环节——连接、TLS、响应头、空闲复用等。只设 Timeout 会掩盖真实瓶颈。
-
client.Timeout = 10 * time.Second：从Do()开始计时，到resp.Body.Close()结束为止 -
Transport.DialContext中的Timeout控制 TCP 连接建立（如 DNS 解析 + SYN 握手） -
TLSHandshakeTimeout单独约束 TLS 握手，避免因证书链过长或 OCSP 响应慢拖垮整体 -
ResponseHeaderTimeout是关键：它限制“收到状态行和响应头”的时间，防止后端卡在生成 body 前
何时必须用 context.WithTimeout 替代 client.Timeout
当请求生命周期需被外部逻辑统一取消（比如用户主动中断、父任务超时、熔断器触发），context 是唯一可靠方式。单纯靠 client.Timeout 无法实现跨 goroutine 协同取消。
-
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)才真正把超时信号透传到底层连接 - 若同时设置了
client.Timeout和ctx，以先触发者为准，但ctx可被提前 cancel，client.Timeout不可 - 注意：
context.WithTimeout创建的 ctx 在超时后会返回context.DeadlineExceeded，需用errors.Is(err, context.DeadlineExceeded)判断，而非字符串匹配
容易被忽略的资源泄漏点
超时发生后，resp.Body 可能未被读取或关闭，底层连接不会释放回连接池，反复触发会导致 http: server gave HTTP response to HTTPS client 或 dial tcp: lookup failed 等伪装错误。
- 永远在
if err != nil分支里检查err是否为*url.Error，再判断err.Timeout() - 即使超时，也要尝试
resp.Body.Close()（如果 resp 不为 nil），否则连接泄漏 - 对流式响应（如 SSE、大文件下载），必须用
io.CopyN或带超时的io.ReadFull控制读取节奏，不能依赖client.Timeout
真正难的是让超时时间与业务 SLA 对齐——比如支付回调要求 2s 内返回，那 ResponseHeaderTimeout 得设成 1.2s，留出 0.8s 处理 body 和业务逻辑。硬编码 5s 或 10s 看似安全，实则掩盖了性能退化。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
