Go 上下文已取消但下游请求仍未退出怎么办

Go 里的 cancel() 只负责关闭上下文的取消信号，并不会强行终止任意 goroutine。下游请求仍未退出时，先看调用边界是否接收并使用了同一个 ctx：HTTP 要通过 NewRequestWithContext 或 Request.WithContext 绑定，数据库要调用 QueryContext 这类方法；如果自定义函数只是收到了 context.Context 却没有监听 Done()，取消自然不会改变它的阻塞状态。

先判断取消信号是否真的到达下游

Context 负责携带 deadline、取消信号和请求范围内的值。父 Context 被取消后，派生 Context 也会取消，但取消传播只改变 Done() 和 Err() 的状态；下游函数必须主动读取它。尤其要检查这三个位置：入口是否把请求 Context 传入业务层，业务层是否原样传给客户端，客户端是否选择了带 Context 的方法。

func handle(ctx context.Context, client *http.Client) error {
	// 先派生一个有明确边界的子 Context，并在函数返回时释放定时器资源。
	ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
	defer cancel()

	// 取消原因和下游耗时要一起记录，便于区分超时与业务主动取消。
	start := time.Now()
	err := callDownstream(ctx, client)
	if err != nil {
		return fmt.Errorf("下游调用耗时 %s: %w", time.Since(start), err)
	}
	return nil
}

如果入口的 ctx.Err() 已经是 context deadline exceeded，但下游日志仍显示使用了一个没有 deadline 的 Context，就说明信号在调用链中被替换了。重点搜索 context.Background()、context.TODO() 和没有 Context 后缀的调用。

遇到这类上下文已经取消，但下游关联请求还在执行的异常场景，你可以按请求链路逐层传递ctx、为下游调用绑定超时控制、通过子协程通道实现退出信号同步这几个方案排查修复，就能彻底避免请求悬空、资源泄漏的问题。

HTTP 请求必须绑定同一个 Context

HTTP 客户端最容易出现“上层已取消、请求还在等”的原因，是用 http.NewRequest 创建了没有上下文的请求，或者在封装层里丢掉了传入的 ctx。标准库提供了带 Context 的构造方式，调用 client.Do 后，取消信号才能进入 HTTP 请求生命周期。

func callDownstream(ctx context.Context, client *http.Client) error {
	// 请求对象绑定调用方的 Context，避免封装层另起一个脱离请求的生命周期。
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://api.example.test/profile", nil)
	if err != nil {
		return err
	}

	resp, err := client.Do(req)
	if err != nil {
		// 上层取消通常会通过 ctx.Err 或请求错误体现，保留原错误供调用方判断。
		return err
	}
	defer resp.Body.Close() // 无论读取是否成功都关闭响应体，避免连接资源滞留。
	if resp.StatusCode >= http.StatusBadRequest {
		return fmt.Errorf("下游返回 HTTP %d", resp.StatusCode)
	}
	return nil
}

如果使用已有的 *http.Request，可通过 req.WithContext(ctx) 得到带新上下文的副本。不要只在外层设置一个独立的 http.Client.Timeout 就认为完成了传播：客户端总超时能结束请求，但它不替代调用链中的取消语义，也不能让自定义下游接口理解你的业务 Context。

数据库和自定义 API 也要把 Context 当作参数

数据库调用应优先使用 QueryContext、ExecContext 或同类接口；只调用 Query 再在外层等待 ctx.Done()，只能让等待者返回，无法保证数据库操作本身停止。自定义 API 则应把 ctx 放在第一个参数，并在每个可能阻塞的循环或 I/O 边界检查它。

func loadUser(ctx context.Context, db *sql.DB, id int64) error {
	// QueryContext 将取消信号交给 database/sql 和底层驱动处理。
	row := db.QueryRowContext(ctx, "SELECT name FROM users WHERE id = ?", id)
	var name string
	if err := row.Scan(&name); err != nil {
		return err
	}
	return nil
}

func waitForWork(ctx context.Context, jobs 

用退出证据区分三类故障

注意，cancel() 返回并不代表所有工作已经停止。官方文档明确说明取消函数不会等待工作结束，所以需要在服务端日志中记录“取消发生时间”和“下游退出时间”，必要时等待负责 goroutine 的同步信号。这样才能确认是传播修复生效，还是只是调用方提前返回。

常见问题

为什么 ctx.Err() 已经有值，请求仍没有返回？

因为 Context 只发出协作式信号；调用的 API 或阻塞点没有读取它时，工作仍可能继续。更换为带 Context 的 API，或在自定义阻塞处监听 Done()。

可以在每一层都重新创建 context.Background() 吗？

请求链路中不应这样做。只有真正脱离请求生命周期的独立任务才应明确创建新的根 Context，并承担自己的超时、取消和收尾责任。