最简写法是启动goroutine执行任务并用channel传结果，select等待结果channel或time.After(timeout)；需确保耗时操作在独立goroutine中，避免阻塞。
用 select + time.After 实现函数超时最简写法
Go 里没有内置的“函数级超时”语法，但用 select 配合 time.After 是最轻量、最常用的方式。核心逻辑是：把耗时操作包装成 channel 操作，和超时 channel 一起 select，谁先返回就取谁。
常见错误是直接在 select 里调用阻塞函数（比如 http.Get），这会导致整个 goroutine 卡住，超时机制失效——必须确保耗时操作本身是非阻塞的，或跑在独立 goroutine 中。
- 正确姿势：启动 goroutine 执行任务，用 channel 传结果；
select等待结果 channel 或time.After -
time.After返回的是，不能重复使用，每次超时都要新建 - 超时时间建议用
time.Duration变量传入，方便测试和配置化，别硬写5 * time.Second
func fetchWithTimeout(url string, timeout time.Duration) (string, error) {
ch := make(chan string, 1)
go func() {
resp, err := http.Get(url)
if err != nil {
ch <- ""
return
}
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
ch <- string(body)
}()
<pre class="brush:php;toolbar:false;">select {
case result := <-ch:
return result, nil
case <-time.After(timeout):
return "", fmt.Errorf("timeout after %v", timeout)
}}
为什么不能只用 context.WithTimeout 而不用 select？
context.WithTimeout 本身不提供“自动中断运行中函数”的能力，它只是传递取消信号。能否响应取消，取决于你调用的函数是否支持 context.Context 参数（如 http.Client.Do、database/sql.QueryContext）。如果底层函数不支持，context 就只是个摆设。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
而 select + channel 是通用协程协作机制，不依赖函数签名，适用于任何可封装为 goroutine 的操作（比如自定义重试逻辑、调用不支持 context 的第三方库、甚至 sleep 或计算密集型任务的粗粒度中断）。
- 支持 context 的场景（推荐）：
http.NewRequestWithContext、client.Do(req) - 不支持 context 的场景（必须用 select）：调用 C 函数、旧版 SDK、自己写的无 context 接口函数
- 混合用法常见：用 context 控制 HTTP 层，再用
select包一层总超时，防止单个请求卡死整个流程
超时后 goroutine 泄漏怎么避免？
上面的 fetchWithTimeout 示例有个隐患：如果 http.Get 在超时后才返回，goroutine 会把结果写进已满的 ch（容量为 1），然后永远阻塞——造成 goroutine 泄漏。
根本原因是 channel 容量太小，且没做“超时后忽略结果”的防护。修复的关键是让发送端不阻塞：
- 把 channel 改成带缓冲的（如
make(chan string, 1)已够，但接收端必须保证一定消费） - 更稳妥：在 goroutine 内部用
select带 default，只在 channel 可写时发结果，否则丢弃 - 或者用
context配合 goroutine 取消，让任务主动退出（需函数支持）
go func() {
resp, err := http.Get(url)
if err != nil {
select {
case ch <- "": // 尝试发送
default: // 拒绝阻塞
}
return
}
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
select {
case ch <- string(body):
default:
}
}()实际项目中容易被忽略的边界点
真实服务里，超时不是设个数字就完事。几个高频踩坑点：
- HTTP 客户端自身也有超时（
Timeout、IdleConnTimeout），和外层select超时叠加可能引发双重等待，建议外层超时 > 客户端超时 - 重试逻辑如果放在超时外层（比如先
select，失败后再重试），可能累积超时——应把重试封装进 goroutine，整体受统一超时约束 -
time.After在长时间运行服务中频繁创建会有小对象分配压力，高 QPS 场景可用time.NewTimer复用，但注意复用前必须Reset且Stop防泄漏 - 测试超时逻辑时，别只 mock 成功路径，一定要构造慢响应（如
time.Sleep(2 * timeout)）验证是否真能中断
超时控制的本质是权衡：设太短，误伤正常请求；设太长，拖垮整体延迟。真正难的不是写对 select，而是理清每个环节的预期耗时和失败传播路径。
