最可靠方式是用 context.WithTimeout 包裹函数调用，要求函数接收 context.Context 参数并主动检查 ctx.Done()；若函数不支持 context，则需 goroutine+channel 包装并手动清理资源。
用 context.WithTimeout 包裹函数调用最可靠
Go 原生不支持“给函数加超时”，必须靠主动协作——让被调用函数能感知取消信号。最稳妥的方式是把目标函数改造成接收 context.Context 参数，并在内部定期检查 ctx.Err()。外部用 context.WithTimeout 创建带截止时间的上下文，再传进去。
常见错误是只用 time.AfterFunc 或 goroutine + channel 模拟超时，但这类方式无法真正中断正在执行的函数（比如阻塞在系统调用、死循环或未响应的第三方库调用），只能做到“不再等待结果”，资源仍可能泄漏。
- 函数签名需显式接受
ctx context.Context，并在关键点调用select监听ctx.Done() - 超时后，
ctx.Err()会返回context.DeadlineExceeded，可用于区分超时和其他错误 - 不要在函数内部直接调用
time.Sleep或net.Conn.SetDeadline后忽略上下文——这些操作本身可能不响应 cancel，需配合ctx.Done()检查
第三方函数没提供 context 参数怎么办
如果调用的是标准库（如 http.Client.Do）或主流包（如 database/sql 的 QueryContext），优先找带 Context 后缀的方法。若真没有（比如某些老旧 SDK 或闭源库），只能用 goroutine + channel + select 做“外部超时包装”，但要注意资源清理。
示例：包装一个无 context 支持的阻塞函数 legacyBlockOp()
ch := make(chan error, 1)
go func() {
ch <- legacyBlockOp() // 这里无法中断，但可避免主 goroutine 卡住
}()
select {
case err := <-ch:
return err
case <-time.After(5 * time.Second):
return fmt.Errorf("operation timeout")
}- goroutine 仍会继续运行，若它持有文件句柄、连接或内存，可能造成泄漏
- 不能假设
legacyBlockOp会在超时后自动退出；它可能永远卡住 - 这种模式仅适用于“你确定它最终会结束”或“副作用可忽略”的场景
time.After 和 time.Timer 别乱用
有人用 time.After 配合 select 实现超时，看起来简洁，但容易踩坑：
-
time.After每次调用都会新建一个Timer，如果 select 未命中该 case，timer 不会自动停止，可能累积 goroutine 泄漏 - 正确做法是用
time.NewTimer，并在不需要时显式调用timer.Stop() - 更推荐统一用
context.WithTimeout，它内部已处理 timer 管理和 goroutine 安全
错误写法：select { case —— 每次都创建新 timer，且无法回收。
HTTP 请求超时要分层设置
HTTP 客户端超时不是单设一个 context.Timeout 就够的。标准库 http.Client 自身有三类超时，和 context 超时共同作用：
-
client.Timeout：整个请求（包括连接、读写）总耗时上限，优先级低于 context -
client.Transport中的DialContext、ResponseHeaderTimeout等：控制各阶段细节 - 传入
req.WithContext(ctx)：让底层 net.Conn 能响应 cancel，尤其对 TLS 握手、DNS 解析有效
如果只设 context.WithTimeout 但 client.Timeout 是 0（默认无限），遇到慢 DNS 或 TLS 卡住时，context 可能来不及生效。
实际项目里，最易被忽略的是函数内部是否真正响应了 context —— 很多开发者只加了参数却忘了在循环、IO 或 sleep 前加 select 检查。超时机制不是开关，而是需要函数每一处潜在阻塞点都主动配合。
