Go context 为什么取消后任务仍未停止

很多 Go 服务都有过这个现象：上游请求已经超时，代码也调用了 cancel()，日志里却还能看到后台任务继续打印，甚至 goroutine 数量迟迟不降。这里最容易误解的一点是，context 不是强制杀死 goroutine 的按钮，它只负责传播“这项工作已经不需要继续了”的信号。任务本身必须在循环、等待点或下游 API 处主动观察信号并返回。

官方资料：https://pkg.go.dev/context

取消成功只代表信号已经发出，不代表业务代码已经结束。判断任务是否停止，要看它是否从自己的工作循环和阻塞调用中返回。

为什么 cancel 之后 goroutine 还会运行

context.WithCancel 返回一个派生上下文和一个取消函数。调用取消函数后，Done() 通道会关闭，Err() 通常返回 context.Canceled；但是 Go 不提供从外部安全地强杀任意 goroutine 的机制。goroutine 如果一直计算、一直睡眠，或者卡在不支持 context 的调用里，就没有机会处理这个信号。

循环里必须在安全边界读取 Done

最小可行的修复，是在每轮工作开始前或等待期间监听 ctx.Done()。不要只在 goroutine 启动时检查一次，因为取消可能发生在任意一轮之后。

package main

import (
	"context"
	"fmt"
	"time"
)

func consume(ctx context.Context, jobs 

这个例子只保证消费者能响应取消；如果生产者在无缓冲 channel 上发送，而消费者已经退出，生产者仍可能卡住。因此生产者也要监听同一个 context，或者使用不会让收尾永远等待的发送方式。

阻塞调用要把 context 传到真正执行工作的地方

外层函数即使监听了 ctx.Done()，也不代表内部的 HTTP、数据库或 RPC 调用会自动停止。调用必须使用带 context 的 API，并且不能在中间重新换成 context.Background()。

func queryAlbum(ctx context.Context, db *sql.DB, id int) error {
	// 派生超时并在函数返回时释放计时器资源。
	queryCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
	defer cancel()

	var title string
	// QueryRowContext 才能把上游取消继续传给数据库驱动。
	err := db.QueryRowContext(queryCtx,
		"SELECT title FROM albums WHERE id = ?", id).Scan(&title)
	if err != nil {
		// 上游取消和数据库自身错误要保留给调用方区分。
		return fmt.Errorf("查询专辑：%w", err)
	}
	fmt.Println("标题：", title)
	return nil
}

同样的原则适用于 HTTP 客户端：使用 http.NewRequestWithContext 或把 context 交给已有的请求构造函数。不要在重试循环里每次都创建一个脱离父请求的 Background，否则上游早已结束，下游仍会继续排队。

四步排查：到底是谁没有退出

1. 先看信号：在取消分支打印 ctx.Err()，确认调用方确实执行了 cancel，而不是只设置了一个不会读取的布尔变量。
2. 再看传播：从入口到 worker、HTTP、数据库逐层检查函数签名，确认 context 没有被替换成 Background。
3. 缩短等待：把长计算拆成小块，在每块之间检查取消；把不可取消的等待改成带 context 的 API 或定时器。
4. 检查收尾：用 sync.WaitGroup 等待 worker 返回，并确认 worker 退出后不会向无人接收的结果 channel 发送。

常见问题

调用 cancel 后能不能强制杀死 goroutine？

不能。取消是协作式机制，必须由 goroutine 自己读取信号并返回；无法控制的第三方调用需要换成支持 context 的接口或设置它自己的超时。

为什么用了 select 仍然退出很慢？

可能是 select 两次执行之间存在长计算，也可能是代码已经进入不可取消的阻塞调用。把检查点前移并把 context 传入下游，通常比增加更多日志更有效。

收到 context.Canceled 是否一定是程序错误？

不一定。它可能只是客户端断开、上游超时或用户主动取消。关键是让调用方能区分取消、超时和业务错误，并确保资源得到释放。

排查这类问题时，先记住一个判断顺序：取消信号有没有发出，是否沿调用链传播，工作点是否主动监听，最后才看 goroutine 的收尾是否被 channel 或下游资源卡住。只要这四层都闭合，context 才真正能控制任务生命周期。