在 Go 中，context 是控制协程（goroutine）生命周期最标准、最推荐的方式。它不直接“杀死”协程，而是通过传递信号（如取消、超时）让协程主动退出，避免资源泄漏和竞态问题。
用 context.WithCancel 主动取消协程
当你需要在外部手动触发停止时，context.WithCancel 是最基础的选择。它返回一个可取消的 context 和一个 cancel 函数。
- 调用
cancel()后，该 context 的Done()通道会立即关闭，监听它的 goroutine 可以感知并退出 - 务必在适当时候调用
cancel()，否则会导致 context 泄漏（尤其是子 context） - 不要重复调用
cancel()，它是幂等的，但多次调用无意义且可能掩盖逻辑错误
示例：启动一个轮询任务，5 秒后手动取消
ctx, cancel := context.WithCancel(context.Background()) defer cancel() // 防止忘记取消go func(ctx context.Context) { ticker := time.NewTicker(1 * time.Second) defer ticker.Stop() for { select { case <-ctx.Done(): fmt.Println("轮询已取消:", ctx.Err()) // context canceled return case <-ticker.C: fmt.Println("执行一次轮询") } } }(ctx)
time.Sleep(5 * time.Second) cancel() // 主动触发取消
用 context.WithTimeout 实现自动超时退出
当操作必须在指定时间内完成时，context.WithTimeout 更简洁安全。它内部基于 WithCancel + 定时器，在超时后自动调用 cancel()。
立即学习“go语言免费学习笔记（深入）”；
- 超时时间从调用
WithTimeout的那一刻开始计时，不是从 goroutine 启动时 - 即使 goroutine 尚未启动，超时仍会触发，所以适合包装 I/O、HTTP 请求等不确定耗时的操作
- 记得检查
ctx.Err()，区分是超时（context.DeadlineExceeded）还是被手动取消
示例：限制 HTTP 请求最多等待 3 秒
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel()req, _ := http.NewRequestWithContext(ctx, "GET", "https://www.php.cn/link/85c19375f0c12c6793bf66b4e2666dc4", nil) resp, err := http.DefaultClient.Do(req) if err != nil { if errors.Is(err, context.DeadlineExceeded) { fmt.Println("请求超时") } else { fmt.Println("其他错误:", err) } return } defer resp.Body.Close()
向下传递 context 并保持链路一致性
协程之间要形成可取消的调用链，关键在于“传递 context”，而不是每个 goroutine 都用 context.Background()。
- 所有可能被取消或超时的函数，都应接收
ctx context.Context作为第一个参数 - 调用子任务时，用
context.WithXXX(parentCtx, ...)创建子 context，确保取消信号能逐层向下传播 - 不要把 context 存在结构体里长期持有（除非明确需要），容易造成生命周期混乱
常见错误写法：go doWork(context.Background()) —— 这样子 goroutine 就脱离了父级控制。
正确做法：
func main() {
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
go doWork(ctx) // 传入父 context
}
func doWork(ctx context.Context) {
// 可继续派生子 context，例如加一个更短的超时
subCtx, subCancel := context.WithTimeout(ctx, 2*time.Second)
defer subCancel()
select {
case <-subCtx.Done():
fmt.Println("子任务超时或被取消")
case <-time.After(1 * time.Second):
fmt.Println("子任务完成")
}}
注意 Done 通道的使用方式和常见陷阱
ctx.Done() 是一个只读的 ，用于监听取消信号。它的行为有几点必须清楚：
- 不能向
ctx.Done()发送数据，否则编译报错；也不能关闭它，这是 context 内部管理的 - 如果 context 没被取消或没超时，
ctx.Done()会一直阻塞，所以必须配合select使用，且至少有一个非Done分支（如default或其它 channel） - 不要用
if ctx.Done() != nil判断是否可取消 —— 所有 context 都有Done()方法，未取消时它只是个未关闭的 channel - 若需获取取消原因，统一用
ctx.Err()，它在取消后返回context.Canceled，超时后返回context.DeadlineExceeded
不推荐：
// ❌ 错误：没有 default 或其它 case，会永久阻塞
select {
case <-ctx.Done():
return
}推荐：
// ✅ 正确：有实际工作分支
select {
case <-ctx.Done():
return
case data := <-ch:
process(data)
}context 不是万能的“协程杀手”，而是一套协作式生命周期协议。核心原则就一条：谁创建 context，谁负责 cancel；谁接收 context，谁负责监听 Done 并及时退出。只要每个环节都遵守，就能写出健壮、可预测的并发程序。
