Go中不能仅用time.After做超时，因其返回的chan无法取消、不传播信号、不通知下游释放资源，易致goroutine泄漏；必须配合context.Context由任务主动响应Done()退出。
Go 里没有“强制中断任务”的能力，超时控制必须靠任务自己配合 context.Context 主动退出。用 time.After 或 time.Sleep 单独做超时，几乎必然导致 goroutine 泄漏或资源未释放。
为什么不能只用 time.After 做超时
它只返回一个单次触发的 chan time.Time，无法取消、无法传播信号、无法通知下游 I/O 关闭连接。常见错误是写成：
select {
case <-time.After(5 * time.Second):
return errors.New("timeout")
case result := <-doSomething():
return result
}这段代码在 doSomething() 内部阻塞（比如读数据库、发 HTTP 请求）时，time.After 到点就走，但那个阻塞操作还在后台跑着——goroutine 没被唤醒，连接没被关，定时器也没被回收。
- 每次调用
time.After都新建一个 timer，高频轮询会堆积 timer 对象 - 它不和
http.Client、database/sql等标准库联动，超时后底层 TCP 连接仍保持打开 - 无法区分是“真超时”还是“网络抖动”，错误处理只能靠字符串匹配，不可靠
context.WithTimeout 是唯一推荐的起点
所有可中断的操作（HTTP 请求、DB 查询、gRPC 调用、文件读取等）都应接收 context.Context 参数，并在阻塞点检查 ctx.Done()。标准库已全面支持：
立即学习“go语言免费学习笔记（深入）”；
-
http.NewRequestWithContext(ctx, ...)和client.Do(req)会在超时后自动关闭底层连接 -
db.QueryContext(ctx, ...)会中止查询并释放连接池中的连接 -
grpc.ClientConn.Invoke(ctx, ...)依赖 context 控制整个 RPC 生命周期
关键习惯：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
ctx, cancel := context.WithTimeout(parentCtx, 3*time.Second)后，**必须 defer cancel()**，否则内部 timer 不释放 - 不要把同一个
ctx传给多个 goroutine 后各自defer cancel()—— 第二个cancel()无效且易掩盖逻辑错误 - 超时时间从
WithTimeout调用那一刻开始计，和任务是否立刻执行无关
HTTP 客户端必须分层设超时，不能只靠 context
context.WithTimeout 管整体生命周期，但网络请求各阶段需独立控制：
- 连接建立（DNS + TCP）：用
http.Transport.DialContext配&net.Dialer{Timeout: 3 * time.Second} - TLS 握手：用
http.Transport.TLSHandshakeTimeout（HTTPS 必设） - 请求写出、响应读入：由
context自动覆盖，无需额外干预 -
禁用
http.Client.Timeout：它已过时，且与 context 行为冲突，优先级难预测
错误处理要精确判断：
-
errors.Is(err, context.DeadlineExceeded)→ context 超时（最常见） -
err != nil && strings.Contains(err.Error(), "timeout")→ ❌ 别这么干，版本升级可能崩 -
net.OpError.Timeout()→ 底层 I/O 级超时（如 DialContext 超时）
纯计算型任务怎么加超时
如果任务不涉及 channel、I/O、sleep 或其他可响应 ctx.Done() 的操作，context 完全无效。例如：
for i := 0; i < 1e9; i++ {
// 纯 CPU 计算，没地方插 ctx.Done() 检查
}这种场景必须手动插入中断点：
- 循环体内部定期
select { case - 或每 N 次迭代后显式检查
if ctx.Err() != nil { return ctx.Err() } - 避免无休止的
for {}，尤其在并发 goroutine 中——它既无法被取消，也吃光 CPU
真正麻烦的是那些不支持 context 的第三方库。这时只能靠外部监控 goroutine + time.After 触发 cancel()，但必须确保目标操作已进入可中断状态（比如已关闭输入 channel），否则 cancel() 只是发了个信号，没人听。
