优先用 context.WithTimeout 而非 time.After + select；需同时监听 ctx.Done() 和业务 channel，检查 ctx.Err() 类型区分超时与取消，并务必调用 cancel() 防泄漏。
用 context.WithTimeout 控制 goroutine 超时最稳妥
直接上结论：别自己手撸 time.After + select 去等超时，优先用 context.WithTimeout。它不只是“加个定时器”，而是把取消信号、超时错误、父子传递全包圆了。
常见错误是只监听 ctx.Done()，却忽略 ctx.Err() 的具体类型——超时和手动取消要区分处理，否则日志里全是 context canceled，根本分不清是用户关了页面，还是下游接口卡死了。
- 必须在
select里同时监听ctx.Done()和业务 channel，不能只等超时 -
WithTimeout返回的context.Context和cancel函数必须成对调用，漏掉cancel()会泄漏 goroutine - 超时时间建议设为
time.Millisecond * 500这种显式单位，别写500（单位不明确，容易误读）
ctx, cancel := context.WithTimeout(context.Background(), time.Second*3)
defer cancel() // 必须 defer，哪怕提前 return
<p>select {
case result := <-doWork(ctx):
handle(result)
case <-ctx.Done():
if errors.Is(ctx.Err(), context.DeadlineExceeded) {
log.Println("task timed out")
}
}为什么 time.Timer 单独用容易出问题
time.Timer 看似轻量，但单独拿来控制并发任务超时，几乎必然踩坑：它不传播取消、不联动其他 goroutine、无法被父 context 主动终止。
典型翻车场景是“启动多个带 Timer 的 goroutine，然后想统一中断”——做不到。Timer 只管自己那一秒，cancel 信号传不进去。
立即学习“go语言免费学习笔记（深入）”；
-
time.AfterFunc启动的回调无法取消，一旦注册就一定会执行（哪怕你后续不关心结果） -
time.NewTimer必须手动Stop()，否则即使超时触发了，底层 timer 仍驻留 runtime，累积多了会拖慢调度 - 和
context混用时，别在select里同时写和 <code>，重复响应导致逻辑错乱
HTTP 客户端请求超时必须分三层设
Go 的 http.Client 超时不是设一个 Timeout 就完事。DNS 解析、TCP 连接、TLS 握手、服务器响应，每个阶段都可能卡住，单靠 context.WithTimeout 拦不住底层阻塞。
比如 DNS 被污染导致解析卡 30 秒，ctx 虽然超时了，但 net.Dial 还在等系统 resolver 返回——此时 goroutine 已泄漏。
- 必须配
http.Client.Timeout（整个请求生命周期上限） - 再设
http.Transport的DialContext、TLSHandshakeTimeout、ResponseHeaderTimeout - 发起请求时仍要传
ctx，用于中途主动取消（比如用户点了取消按钮）
client := &http.Client{
Timeout: 5 * time.Second,
Transport: &http.Transport{
DialContext: func(ctx context.Context, netw, addr string) (net.Conn, error) {
return (&net.Dialer{
Timeout: 2 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext(ctx, netw, addr)
},
TLSHandshakeTimeout: 2 * time.Second,
ResponseHeaderTimeout: 3 * time.Second,
},
}嵌套 context 超时要注意 cancel 顺序
当一个任务既要总超时，又要内部子任务单独超时（比如调三个微服务，每个最多 800ms，整体不能超 2s），很多人会嵌套 WithTimeout，但 cancel 调用顺序错了就会让子 context 不释放。
核心原则：子 context 的 cancel 必须在父 context 超时前被调用，否则子 goroutine 会一直等到父 timeout 才结束，浪费资源。
- 子 context 的
cancel应该放在子 goroutine 内部 defer，而不是外层 defer - 不要用
context.WithCancel(parent)+ 手动计时器去模拟超时，语义不清且难测试 - 如果子任务间有依赖（如 A 成功才跑 B），别给每个都设独立 timeout，而应共用同一个子 ctx，避免 B 在 A 还没返回时就被 cancel
真正麻烦的从来不是写几行超时代码，而是搞清“谁该响应哪个 cancel 信号”——context 树的生命周期管理，比语法本身更需要设计意识。
