context.withtimeout 是首选方案，因其通过取消信号传播实现资源安全释放，支持嵌套传递、并发安全，且标准库原生集成；而 time.after 等方式易致资源泄漏。
context.WithTimeout 为什么是首选方案
Go 的超时控制本质是“取消信号的传播”，不是靠轮询或 sleep。直接用 time.After 或 time.Sleep 配合 select 看似简单，但无法释放底层资源（比如 HTTP 连接、数据库连接、goroutine），容易堆积泄漏。
context.WithTimeout 把超时和取消统一到一个 Context 接口里，所有标准库（http.Client、database/sql、net.DialContext）都原生支持它。
- 超时后自动调用
cancel()，触发所有监听该ctx.Done()的 goroutine 退出 - 可嵌套传递，下游函数无需重复写超时逻辑
- 不依赖全局状态，天然适合并发安全场景
示例：HTTP 请求带 5 秒超时
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel() resp, err := http.DefaultClient.Do(req.WithContext(ctx))
http.Client.Timeout 和 context.WithTimeout 到底该用哪个
http.Client.Timeout 是客户端级别的默认超时，作用于整个请求生命周期（从 DNS 解析到响应 body 读完）。但它不可动态调整，且一旦设置就影响所有请求，缺乏灵活性。
context.WithTimeout 是请求粒度的，每次调用可独立设时长，还能结合 context.WithValue 传额外元信息（如 traceID）。
- 如果你做的是网关、代理或需要按业务路径差异化超时（例如“用户查询 2s，报表导出 30s”），必须用
context.WithTimeout - 如果只是写个内部工具脚本，且所有请求超时一致，
http.Client.Timeout更简洁 - 二者同时存在时，
context的超时优先级更高，会提前中断请求
常见错误：只设了 http.Client.Timeout，却在 select 里手动等 time.After，结果上下文没传给 Do()，超时根本不起作用。
select + ctx.Done() 里忘了 close(done) 会卡死
很多人手写带超时的异步操作，习惯这么写：
done := make(chan error, 1)
go func() { done <p>问题在于：如果 <code>doSomething()</code> 慢于 3 秒，<code>done</code> channel 会一直阻塞，goroutine 泄漏；更糟的是，如果后续又用这个 <code>done</code> 做其他事，可能因未关闭而 panic。</p><p>正确做法是用 <code>context</code> 驱动，并确保 goroutine 自行清理：</p><pre class="brush:php;toolbar:false;">ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
done := make(chan error, 1)
go func() {
defer close(done) // 关键：不管成功失败都要 close
select {
case
-
defer close(done)防止 channel 永远不关闭 -
select在 goroutine 内部先检查ctx.Done()，避免无意义执行 - 外层
select和内层共享同一个ctx，保证信号同步
time.After 和 time.NewTimer 在循环里别乱用
time.After 每次调用都会新建一个 Timer，如果放在高频循环里（比如每秒检查一次健康状态），会持续创建并等待，最终吃光系统 timer 资源（Go runtime 有 timer 数量上限）。
- 短期一次性等待（如单次超时判断）用
time.After没问题 - 循环中需反复等待，必须用
time.NewTimer+Reset() - 用完记得
Stop()，否则Timer不会被 GC
示例：每 5 秒重试一次，最多等 30 秒
t := time.NewTimer(30 * time.Second) defer t.Stop() for i := 0; i <p>真正要小心的是把 <code>time.After</code> 放在 for 循环顶部——那等于每轮都 new 一个 Timer，且旧的还没被回收。</p><p>超时不是加个 <code>time.After</code> 就完事，关键在资源归属和信号链路是否完整。context 是 Go 的超时基础设施，绕开它自己造轮子，十有八九会在某次压测或长连接场景下暴露 goroutine 泄漏。</p>
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
