最常用方式是用context.WithTimeout创建带超时的context，超时后ctx.Err()返回context.DeadlineExceeded；需注意计时起点、及时调用cancel、避免重复cancel；HTTP超时需分层设置；循环中勿反复创建timeout context。
用 context.WithTimeout 控制单次任务超时
最常用也最直接的方式是给任务套一层带超时的 context。它会在指定时间后自动取消，下游通过监听 ctx.Done() 捕获取消信号。
注意：WithTimeout 内部调用 WithDeadline，传入的是相对时间，不是绝对时间戳；超时后 ctx.Err() 返回 context.DeadlineExceeded，不是 nil。
- 超时时间从调用
WithTimeout那一刻开始计时，和任务是否立刻执行无关 - 如果任务提前完成，应主动调用
cancel()释放资源（虽然不调也不会泄漏，但属于良好习惯） - 不要把同一个
ctx多次传给不同 goroutine 并重复 defer cancel() —— 第二个cancel()会静默失败
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
<p>select {
case <-time.After(3 * time.Second):
fmt.Println("task done")
case <-ctx.Done():
fmt.Println("timeout:", ctx.Err()) // timeout: context deadline exceeded
}用 context.WithCancel + 手动触发实现条件性超时
当超时逻辑依赖运行时状态（比如重试次数、响应码、部分数据已返回），不能只靠固定时间，就得自己控制 cancel() 的时机。
典型场景：HTTP 请求收到 200 但 body 流式解析卡住，或第三方 SDK 不支持 context，只能靠外部 goroutine 监控并手动 cancel。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须确保只调用一次
cancel()，多次调用无副作用但没必要 - 在 goroutine 中调用
cancel()前，确认目标操作确实已进入可中断状态（例如已关闭 channel、已退出 for-select 循环） - 若任务本身无 context 支持，cancel 后仍需额外同步机制（如 close done channel）通知主流程退出
ctx, cancel := context.WithCancel(context.Background())
done := make(chan error, 1)
<p>go func() {
err := doSomethingWithoutContext()
done <- err
}()</p><p>select {
case err := <-done:
if err != nil {
log.Println("task failed:", err)
}
case <-time.After(5 * time.Second):
cancel() // 主动中断
log.Println("forced cancel after 5s")
}HTTP Client 超时必须分层设置
Go 的 http.Client 自身有超时字段，和 context 超时是两套机制，**不能互相替代**。只设 context 超时，无法阻止底层 TCP 连接卡在 SYN 或 TLS 握手；只设 client 超时，又无法中断已发出请求但服务端迟迟不返回响应体的场景。
-
client.Timeout：整个请求生命周期上限（连接 + 请求头 + 响应头 + 响应体读取） -
client.Transport.DialContext和TLSHandshakeTimeout：控制连接建立阶段 -
context超时：用于在业务逻辑层快速放弃，比如用户取消、上游已超时、熔断触发
client := &http.Client{
Timeout: 10 * time.Second,
Transport: &http.Transport{
DialContext: (&net.Dialer{
Timeout: 3 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
TLSHandshakeTimeout: 3 * time.Second,
},
}
<p>ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
defer cancel()</p><p>req, _ := http.NewRequestWithContext(ctx, "GET", "<a href="https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39">https://www.php.cn/link/710ba53b0d353329706ee1bedf4b9b39</a>", nil)
resp, err := client.Do(req)避免 context.WithTimeout 在循环中反复创建
在 for 循环里每次新建 timeout context，容易造成大量 timer 对象堆积（尤其超时时间短、循环频次高），GC 压力上升，甚至触发 runtime.timer 相关 panic。
真正需要 per-iteration 超时的场景，应复用 timer 或改用 time.AfterFunc + 标志位；若只是想限制整组任务总耗时，用一个顶层 context 更合适。
- 错误写法：
for i := range items { ctx, _ := context.WithTimeout(parent, 100*time.Millisecond); ... } - 正确做法：外层统一加超时，内部用 channel 或 select 控制单次尝试；或用
time.NewTimer复用 - 注意
context.WithTimeout返回的cancel函数必须被调用，否则底层 timer 不会回收
超时控制真正的复杂点不在 API 调用，而在任务是否真的可中断 —— 如果函数内部没检查 ctx.Done()、没把 context 透传到底层 I/O、或用了不支持 cancel 的第三方库，那再严格的 timeout 设置也只是“假装超时”。
