Go http.Client 没设置 Timeout 为什么请求会挂住

如果代码只写了 http.Get 或创建了一个没有设置 Timeout 的 http.Client，请求“挂住”并不一定是 Go 卡死了。http.Client.Timeout 的零值就是“不设总超时”，连接建立、重定向、等待响应头以及读取响应体都可能继续等待。

修复的第一步是给一次调用设定明确的总预算，例如 3 秒；如果还要区分连接、响应头和响应体，再把 Context 或 Transport 的阶段参数补上。

官方资料：https://pkg.go.dev/net/http#Client

先确认：真正没有时限的是哪一层

一个最容易忽略的写法是直接使用默认客户端：

package main

import "net/http"

func fetch(url string) (*http.Response, error) {
	// DefaultClient 的 Timeout 为零，调用不会自动获得总时限。
	return http.Get(url)
}

即使改成显式的 http.Client{}，结果也一样：字段的零值仍然表示不设总超时。只要对端接受了连接却迟迟不结束响应，调用方就可能长期停在 Do、读取响应头或读取 Response.Body 的阶段。

排查时可以先把“挂住”拆成三个观察点：没有连上、已经发出请求但没有响应头、已经拿到响应头却读不完响应体。它们都可能表现为调用迟迟不返回，但根因和可调参数不同。

用一个总预算先把无限等待改成可判断的失败

如果业务只需要“这次 HTTP 调用最多等多久”，先设置 http.Client.Timeout，不要一开始就把所有 Transport 参数拆散。下面用 3 秒作为示例预算：

package main

import (
	"fmt"
	"io"
	"net/http"
	"time"
)

func fetch(url string) error {
	client := &http.Client{
		// 总预算覆盖连接、重定向和响应体读取，避免零值带来的无限等待。
		Timeout: 3 * time.Second,
	}

	resp, err := client.Get(url)
	if err != nil {
		// 超时会通过 error 返回；这里保留错误，交给上层决定重试或降级。
		return fmt.Errorf("请求失败: %w", err)
	}
	defer resp.Body.Close() // 读取完成后释放连接，便于连接复用。

	_, err = io.Copy(io.Discard, resp.Body)
	if err != nil {
		return fmt.Errorf("读取响应体失败: %w", err)
	}
	return nil
}

这里的 3 秒不是 Go 的默认值，而是业务给这次调用设定的预算。它的意义是把“可能一直等”变成“在预算耗尽时得到错误”，然后由上层记录超时、选择有限次数重试或返回降级结果。

为什么拿到响应头后仍然可能继续等待

Client.Timeout 不只控制建立连接。官方文档明确说明，它还包括重定向和读取响应体，计时器在 Get、Head、Post 或 Do 返回后仍可能影响响应体读取。

因此，下面两种现象都不能仅凭“响应头已经拿到了”判断请求安全结束：

• 服务端返回了响应头，但采用流式传输，响应体迟迟不结束；
• 代码没有关闭 resp.Body，导致连接资源没有按预期回收。

对于调用链已经有截止时间的服务，更适合把请求绑定到 Context，让取消信号跟着请求传播：

package main

import (
	"context"
	"fmt"
	"net/http"
	"time"
)

func fetchWithContext(parent context.Context, url string) error {
	ctx, cancel := context.WithTimeout(parent, 3*time.Second)
	defer cancel() // 无论成功或失败都释放计时器资源。

	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return fmt.Errorf("创建请求失败: %w", err)
	}

	client := &http.Client{Timeout: 4 * time.Second}
	resp, err := client.Do(req)
	if err != nil {
		// 这里保留上下文取消/超时信息，便于上层区分调用预算耗尽。
		return fmt.Errorf("执行请求失败: %w", err)
	}
	defer resp.Body.Close()
	return nil
}

示例把 Context 预算设为 3 秒、Client 总预算设为 4 秒，是为了让上游调用先结束；实际项目应根据调用链统一预算，避免多个层级互相覆盖后难以解释。文章主题是没有设置 Client.Timeout 的挂住问题，Context 是补充取消边界，不是把两种计时器简单相加。

需要定位阶段时，再看 Transport 的三个时间点

如果总超时已经设置，但监控仍需要知道“卡在哪里”，可以把 Transport 的参数当作分段观察点。它们不是对 Client.Timeout 零值的替代品，而是更细的阶段约束：

如果只想修复当前的无限等待，先保留一个明确的 Client.Timeout。只有在阶段指标确实能帮助定位问题时，才增加 Transport 级别的时间点；否则配置会变多，错误归因反而更困难。

按指标判断改动是否生效

可以用同一组请求预算记录改动前后的结果，但不要把“更快”当成结论。一个可复用的记录方式是：

• 改动前：Timeout=0，对端不结束响应时没有自动失败时刻；
• 改动后：Timeout=3s，调用最多等待一个总预算，再返回错误；
• 阶段定位：如果总预算内仍失败，结合错误发生时刻判断是连接、响应头还是响应体阶段；
• 资源结果：成功拿到响应后始终关闭 Response.Body，避免把连接资源问题误判为超时问题。

这组指标验证的是“无限等待是否变成了可处理的失败”和“失败阶段是否可解释”，并不代表服务端性能已经改善。超时只是客户端的边界，不能替代服务端修复。

几个容易误判的边界

1. 把零值当成很短的默认值：Timeout=0 不是立即超时，而是没有总时限。
2. 只设置响应头超时：ResponseHeaderTimeout 不控制响应体读取，流式响应仍需总预算或 Context。
3. 忽略响应体关闭：即使请求没有挂住，也可能留下连接复用和资源回收问题。
4. 把多个超时随意叠加：总预算、Context 和 Transport 参数应从调用链目标倒推，不能只复制一组数字。

所以，最小修复通常是：为复用的 http.Client 设置一个非零 Timeout，对单次请求使用上游传入的 Context，成功拿到响应后关闭响应体，再根据监控需要补充分阶段参数。

相关问题

为什么请求没有报错，却一直停在 Do？因为 Timeout=0 没有总截止时间，而连接、响应头或响应体仍未完成。

设置了 ResponseHeaderTimeout 后还会读不完响应体吗？会。它只限制写完请求后等待响应头的时间，不包含响应体读取。

Client.Timeout 和 Context 超时选哪个？单个客户端需要统一总预算时先设置 Client.Timeout；调用链需要传播取消和截止时间时，再把请求绑定到 Context，并保持预算关系可解释。