在Go的并发编程中，goroutine的启动成本极低，但如何优雅地停止它们却是个老大难问题。一个协程如果永远阻塞在channel接收或者IO操作上，就会变成泄漏的僵尸协程，慢慢蚕食内存和CPU。Go官方给出的答案就是context包：它把取消信号、超时控制、请求级别的元数据打包成一个接口，沿着调用链向下传递。本文将系统讲解context的语法细节和取消信号的实践要点。
一、Context接口的结构与设计原理
先看Context的定义。它是位于context包中的一个接口，包含四个方法：
type Context interface {
Deadline() (deadline time.Time, ok bool)
Done() <-chan struct{}
Err() error
Value(key any) any
}这四个方法各司其职。Done()返回一个只读channel，当context被取消或超时时，该channel会被close。注意这里是关闭channel而不是发送值，这样所有监听方都能立即感知到信号，这是一个非常精巧的设计——向channel发送值只能唤醒一个接收者，而关闭channel能同时唤醒所有等待者。
Err()用来查询取消原因。如果context尚未被取消，返回nil；被取消后返回context.Canceled；超时后返回context.DeadlineExceeded。在实际代码中，判断ctx.Err()的返回值可以帮助我们区分是用户主动取消还是超时触发。
Value()用于在调用链中传递请求数据，比如trace ID、用户身份等。但要注意，官方明确建议不要用它传递函数的可选参数，只传递跨进程或跨API的请求级元数据，否则会让依赖关系变得隐晦难懂。
二、创建可取消的Context：WithCancel与WithTimeout
根context通过context.Background()创建，它永远不会被取消。派生context由四个函数产生：WithCancel、WithTimeout、WithDeadline和WithValue。前三个与取消信号直接相关，来看最基础的WithCancel用法：
ctx, cancel := context.WithCancel(context.Background())
go func(ctx context.Context) {
for {
select {
case <-ctx.Done():
fmt.Println("收到取消信号，退出:", ctx.Err())
return
default:
// 执行正常工作
time.Sleep(200 * time.Millisecond)
fmt.Println("工作中...")
}
}
}(ctx)
time.Sleep(time.Second)
cancel() // 发出取消信号
time.Sleep(300 * time.Millisecond) // 等待子协程退出这段代码展示了标准的协程退出模式：子协程内部用select监听ctx.Done()通道，一旦主协程调用cancel()，Done()返回的channel被关闭，select立即命中该分支，协程安全退出。
最容易踩的坑是忘记调用cancel()。从Go 1.7开始，正确写法是用defer cancel()兜底：
ctx, cancel := context.WithCancel(context.Background()) defer cancel() // 即使提前return也保证释放资源
为什么必须调用cancel？因为WithCancel内部会把新context注册到父context的children集合中，如果不调用cancel，这个注册关系就一直存在，父context被取消时还要遍历它，造成内存无法回收。go vet工具会对未调用的cancel发出警告，写代码时务必留意。
超时场景用WithTimeout更方便，它等价于WithDeadline(time.Now().Add(dur))：
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
select {
case <-time.After(1 * time.Second):
fmt.Println("任务完成")
case <-ctx.Done():
fmt.Println("超时或被取消:", ctx.Err()) // 输出 context deadline exceeded
}三、取消信号的传播机制
context的取消遵循树形传播规则：取消父context时，所有由它派生的子孙context都会被级联取消。这个特性在多层调用中非常有用。假设一个HTTP请求进来，服务端处理函数需要调用数据库查询和下游RPC，那么典型结构是：
func handleRequest(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second)
defer cancel()
// 派生子context给不同分支
queryCtx, queryCancel := context.WithCancel(ctx)
defer queryCancel()
go doQuery(queryCtx)
go doRPC(ctx)
select {
case <-ctx.Done():
http.Error(w, "处理超时", http.StatusGatewayTimeout)
}
}r.Context()是Go 1.7之后net/http内置的请求context，当客户端断开连接时它会自动取消，这个机制可以防止服务端继续做无意义的计算。任何从它派生的子context也都会随之取消，从而把客户端断开这一事件传播到数据库驱动、RPC客户端等底层组件。
需要理解的一点是，取消信号本质上是协作式的。context并不会强制杀死goroutine，它只是广播一个信号，具体要不要退出、怎么清理资源，完全取决于协程内部的代码是否监听了Done()。所以数据库驱动、HTTP客户端等库函数都要求传入ctx参数，就是为了让取消信号能穿透到IO层面，及时中断阻塞中的系统调用。
四、避免goroutine泄漏的实践建议
泄漏场景通常长这样：主协程向子协程发送任务，但不等子协程完成就返回了，子协程阻塞在发送channel上永远出不来。修复方法是让子协程的任务channel也走context控制：
func worker(ctx context.Context, ch <-chan int) {
for {
select {
case <-ctx.Done():
return
case v, ok := <-ch:
if !ok {
return
}
fmt.Println("处理:", v)
}
}
}几条实践原则值得遵守。第一，context作为函数第一个参数传递，变量名约定为ctx，不要把Context塞进结构体长期持有。第二，不要传递nil的context，如果拿不准就传context.TODO()占位。第三，cancel函数可以由多个goroutine并发调用，是安全的，但只应被创建方调用，不要把cancel暴露给下游。第四，WithValue派生的context与取消链无关，值查找是逐层向上遍历的链表，key建议使用自定义的非导出类型，避免不同包之间的key冲突。
排查泄漏可以借助goleak库（uber-go/goleak），在测试用例的TestMain中调用goleak.VerifyTestMain，它会在测试结束后检测是否残留了意外存活的goroutine，配合CI能尽早暴露问题。
五、总结
context的核心是三个概念：通过Done()通道广播取消信号，通过WithTimeout/WithDeadline实现超时控制，通过WithValue传递请求元数据。写并发代码时养成习惯：凡是可能阻塞的goroutine，都要接受一个ctx参数并在select中监听取消信号；凡是创建了可取消的context，都要用defer保证cancel被调用。掌握这两点，goroutine泄漏和无法优雅退出的问题基本就能杜绝了。
Golang contextcontext取消信号context.WithCancel修改时间：2026-09-12 08:52:33