context.WithTimeout是最可靠超时控制方式，自动取消关联goroutine防泄漏；HTTP超时需context与http.Client.Timeout双保险，且Transport需设IdleConnTimeout等。
Go 中 context.WithTimeout 是最常用也最可靠的超时控制方式
直接用 context.WithTimeout 包裹需要限时的操作，比手写定时器或轮询更安全、更符合 Go 的并发模型。它能自动取消关联的 goroutine 和子 context，避免 goroutine 泄漏。
常见错误是只调用 time.After 做 select 超时，但没处理原操作是否仍在运行——比如 http.Get 已发起却未结束，连接可能卡住，资源不会释放。
-
context.WithTimeout会向下游传递取消信号，http.Client、database/sql、net.Conn等标准库组件都原生支持 - 超时时间从调用
WithTimeout开始计时，不是从实际操作启动时开始 - 务必调用返回的
cancel函数（哪怕提前完成），否则 context 持有引用，GC 无法回收
HTTP 请求超时必须用 context + http.Client.Timeout 双保险
仅靠 http.Client.Timeout 无法覆盖所有场景：它只限制整个请求生命周期（包括 DNS 解析、连接、TLS 握手、读响应体），但不支持中间取消；而仅靠 context 又无法约束底层连接建立阶段的阻塞。
正确做法是两者结合：
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel()client := &http.Client{ Timeout: 5 * time.Second, // 防止底层 connect/read 卡死 } req, _ := http.NewRequestWithContext(ctx, "GET", "https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39", nil) resp, err := client.Do(req)
-
http.Client.Timeout设为略大于 context 超时值（如 5.5s），兜底防止 context 取消后 net.Conn 还在等系统调用返回 - 若使用自定义
http.Transport，记得设置IdleConnTimeout和TLSHandshakeTimeout，否则空闲连接或 TLS 握手可能绕过超时 - 不要复用未设置超时的全局
http.Client实例做关键路径调用
select + time.After 仅适用于纯内存操作或已知无副作用的等待
这种写法轻量、直观，但极易误用。它只“等待”一个时间点，并不干预正在运行的逻辑。
典型反例：
select {
case result := <-doHeavyWork():
// doHeavyWork 启动 goroutine 执行耗时任务，但这里无法中止它
case <-time.After(3 * time.Second):
fmt.Println("timeout")
}
- 适合场景：等待 channel 发送、等待锁释放、等待信号量，且发送方/持有方本身支持取消
- 不适合：封装了外部 I/O（如数据库查询、文件读取）、或内部无 context 支持的黑盒函数
-
time.After会创建新 timer，高频调用需注意 GC 压力；短于 1ms 的超时建议用time.AfterFunc或直接检查时间戳
自定义操作超时需显式接收 context.Context 并定期检查 ctx.Err()
如果你写的函数可能被外部限时调用，必须把 context.Context 作为第一个参数，并在循环、IO 等长耗时点主动检查是否已被取消。
例如一个带重试的 API 调用：
func callWithRetry(ctx context.Context, url string) error {
for i := 0; i < 3; i++ {
select {
case <-ctx.Done():
return ctx.Err() // 立即退出
default:
}
if err := doSingleCall(ctx, url); err == nil {
return nil
}
time.Sleep(time.Second)
}
return errors.New("all retries failed")}
- 每次循环开头检查
ctx.Err()，而不是只在入口检查一次 - 调用子函数时仍要传入
ctx，不能假设下层会忽略它 - 如果函数内部启了 goroutine，需用
ctx派生子 context，并确保 goroutine 退出时清理资源（如关闭 channel）
超时不是加个 time.After 就完事的事，关键是取消信号能否穿透到所有相关资源。很多问题出在「以为超时了」，其实 goroutine 还在跑、连接还开着、文件句柄没关——这些都得靠 context 的传播性和显式检查来兜住。
