在Golang的并发编程中，goroutine的启动成本极低，但停止一个正在运行的goroutine却不是自动完成的。如果一段代码执行时间不可控，比如调用了一个响应缓慢的外部接口，或者查询了一张巨大的数据表，那么对应的goroutine就会一直挂着，占用内存和连接资源。当这类卡死的任务越积越多，服务的内存持续上涨，最终可能触发OOM被系统杀掉。context包正是Go官方为解决这类问题提供的标准方案，它可以在超时时间到达或者主动调用取消函数后，向所有派生出去的goroutine广播取消信号。本文将系统地讲解context的原理和用法，并给出多个可以直接落地的代码示例。
一、context包的三种取消方式与底层原理
context包提供了几种创建可取消上下文的函数，分别是context.WithCancel、context.WithTimeout和context.WithDeadline。三者本质上做的是同一件事：返回一个context对象和一个cancel函数。区别只在于取消信号的触发时机。
WithCancel需要手动调用cancel函数来触发取消，适合由业务逻辑主动决定何时中止的场景。WithTimeout接收一个时长参数，比如5秒，表示从现在开始5秒后自动取消。WithDeadline则接收一个绝对时间点，到点自动取消。实际上WithTimeout(parent, d)内部就是调用了WithDeadline(parent, time.Now().Add(d))，两者可以互相替换。
package main
import (
"context"
"fmt"
"time"
)
func main() {
// 方式一：手动取消
ctx1, cancel1 := context.WithCancel(context.Background())
defer cancel1()
// 方式二：超时自动取消，3秒后触发
ctx2, cancel2 := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel2()
// 方式三：指定截止时间
deadline := time.Now().Add(10 * time.Second)
ctx3, cancel3 := context.WithDeadline(context.Background(), deadline)
defer cancel3()
go func(ctx context.Context, name string) {
select {
case <-ctx.Done():
fmt.Println(name, "被取消，原因:", ctx.Err())
case <-time.After(20 * time.Second):
fmt.Println(name, "正常完成")
}
}(ctx1, "任务1")
go func(ctx context.Context, name string) {
select {
case <-ctx.Done():
fmt.Println(name, "被取消，原因:", ctx.Err())
case <-time.After(20 * time.Second):
fmt.Println(name, "正常完成")
}
}(ctx2, "任务2")
go func(ctx context.Context, name string) {
select {
case <-ctx.Done():
fmt.Println(name, "被取消，原因:", ctx.Err())
case <-time.After(20 * time.Second):
fmt.Println(name, "正常完成")
}
}(ctx3, "任务3")
time.Sleep(4 * time.Second)
}
理解context的关键在于Done()方法和Err()方法。Done()返回一个只读的channel，在context未被取消时它永远阻塞，一旦取消信号触发，该channel会被关闭，所有监听它的select分支立即返回。注意这里用的是关闭channel而不是向channel发送值，这样设计的好处是无论有多少个goroutine在监听，都能同时收到通知，不存在值被某个goroutine读走的问题。
Err()方法用来区分取消原因：超时到达返回context.DeadlineExceeded，主动调用cancel则返回context.Canceled。另外还有一个Value()方法用于在context上携带请求级别的数据，但这与取消机制无关，使用时要避免把大量业务数据塞进context。
二、在select中实现超时任务的完整模式
实际业务中最常见的写法是：启动一个goroutine执行耗时任务，主流程通过select同时等待任务结果和超时信号，谁先到就处理谁。这种模式需要注意一个细节——任务goroutine即使超时了也会继续跑完，只是主流程不再等它。因此任务内部也应该检查ctx，及时退出。
package main
import (
"context"
"fmt"
"time"
)
// 模拟一个耗时不可控的任务
func slowTask(ctx context.Context) (string, error) {
resultCh := make(chan string, 1)
go func() {
// 假设这里是耗时操作，比如HTTP请求
time.Sleep(5 * time.Second)
resultCh <- "任务执行完毕，得到结果"
}()
select {
case res := <-resultCh:
return res, nil
case <-ctx.Done():
return "", ctx.Err()
}
}
func main() {
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
start := time.Now()
res, err := slowTask(ctx)
if err != nil {
fmt.Println("出错:", err) // 输出: context deadline exceeded
}
fmt.Println("耗时:", time.Since(start)) // 约2秒，而不是5秒
}
上面的例子中resultCh的缓冲区大小设为1非常重要。如果不设缓冲，超时后主流程已经离开select，任务goroutine在发送结果时会永远阻塞在channel上，造成goroutine泄漏。带缓冲后goroutine可以把结果写入channel后正常退出，垃圾回收器才能回收它。
如果耗时操作本身是分步骤或者带循环的，应该在每一轮迭代开始时检查ctx.Done()，或者直接调用ctx.Err()判断是否已经取消。标准库中的database/sql、net/http都支持传入context，正是通过这种协作式的检查机制实现的。也就是说，context的取消不是强制的抢占，它只是发出信号，真正停止任务还需要代码主动配合监听这个信号。
三、典型应用场景与常见坑
1. 控制HTTP客户端请求超时
func fetchWithTimeout(url string) ([]byte, error) {
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
defer cancel()
req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
if err != nil {
return nil, err
}
resp, err := http.DefaultClient.Do(req)
if err != nil {
return nil, err
}
defer resp.Body.Close()
return io.ReadAll(resp.Body)
}
使用http.NewRequestWithContext创建请求后，一旦超时，底层的TCP连接会被中断，Do方法立即返回错误，不会占用goroutine等待。这是服务端处理上游依赖调用时最推荐的超时控制方式，比单纯依赖client的Timeout字段更灵活，因为同一个client可以针对不同请求设置不同的超时时长。
2. 一个请求链路上的级联取消
context是树状结构的，父context取消时所有子context都会被取消。Web服务中，net/http会在每个请求进来时创建一个带取消信号的context，把它一路传递到数据库查询、缓存读取、下游RPC调用，一旦客户端断开连接，整条链路上的操作都能收到信号并中止，避免做无用功。这也是为什么函数签名惯例是把ctx context.Context放在第一个参数，并且不把context存进结构体字段。
3. 常见坑点总结
- 忘记调用cancel：即使任务正常完成没有超时，也必须调用cancel，否则context内部维护的定时器和父子关系不会被释放，长期运行会泄漏。最稳妥的做法是创建后立即
defer cancel()。 - 把cancel传递给子函数导致误取消：cancel函数应该由创建它的那一层持有和调用，下游函数只接收ctx，避免多处调用造成取消时序混乱。
- 认为取消能杀死goroutine：取消只是信号广播，如果goroutine内部的代码没有监听
Done()，它照样会执行到底。排查goroutine泄漏时可以用runtime的pprof查看goroutine数量变化。 - 用context.Background派生长链超时：超时应该是层层收紧的，子context的超时不能长于父context，否则父context先到期，子超时形同虚设。
掌握context的超时与取消机制，本质上是掌握Go的协作式并发取消模型：发起方负责广播信号，执行方负责响应信号。只要养成ctx作为第一个参数传递、创建即defer cancel的习惯，绝大多数资源泄漏和任务卡死的问题都能从源头上避免。
Golang超时控制context取消机制goroutine协程管理修改时间：2026-09-09 02:40:48