Go context 已取消但 HTTP Handler 为什么还不退出

看到日志里已经打印了 context canceled，但 HTTP Handler 还占着 goroutine 不返回，通常不是 Go 的取消失效，而是把“取消通知”和“强制终止函数”混成了一件事。Request.Context() 被取消后，只有监听 Done() 的代码、支持 context 的下游调用，或主动检查 Err() 的循环，才会协作退出；普通阻塞、无条件等待和 CPU 死循环不会被自动打断。

先记住一句话：context 负责发出“这项工作已经不需要了”的信号，Handler 必须把信号传到阻塞点并自行返回。客户端断开不等于 ServeHTTP 立即结束。

先区分取消通知和 Handler 返回

对服务端请求来说，r.Context() 会在客户端连接关闭、HTTP/2 请求被取消，或 ServeHTTP 返回时被取消。这里有一个容易被忽略的方向：前两种情况会通知 Handler，但不会反过来替你从函数内部“跳出去”。如果 Handler 正卡在一个不支持 context 的调用上，它仍然要等那个调用返回。

因此排查时不要只打印一次 r.Context().Err() 就下结论。要分别观察三个状态：上下文是否已取消、当前工作是否收到信号、Handler 是否执行到了 return。下面的结构图把这三个状态放在同一张图上，图中关系是静态说明，不是运行截图。

检查取消信号是否真正传到阻塞点

最常见的误区是只在 Handler 入口保存了 ctx，但调用下游时重新使用了 context.Background()，或者把一个没有取消能力的函数放进了请求路径。这样日志里可以看到请求已取消，真正耗时的工作却完全不知道。

func loadRemote(ctx context.Context, target string) (*http.Response, error) {
	// 让 HTTP 客户端感知上游请求的取消和截止时间。
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, target, nil)
	if err != nil {
		return nil, err
	}
	return http.DefaultClient.Do(req)
}

func handler(w http.ResponseWriter, r *http.Request) {
	// 入口只取得请求上下文，不创建脱离请求生命周期的 Background。
	resp, err := loadRemote(r.Context(), "https://api.example.test/data")
	if err != nil {
		// 客户端已离开时，直接结束当前 Handler，不再写响应。
		if errors.Is(err, context.Canceled) || errors.Is(err, context.DeadlineExceeded) {
			return
		}
		http.Error(w, "upstream failed", http.StatusBadGateway)
		return
	}
	defer resp.Body.Close() // 读取或放弃响应后都释放连接资源。

	// 这里继续处理 resp；返回前才允许写入仍然有效的响应。
	_, _ = io.Copy(w, resp.Body)
}

这段代码的关键不在于“捕获错误”本身，而在于把同一个 ctx 传给下游。数据库调用应使用 QueryContext、ExecContext 等带上下文的方法；另一个 HTTP 调用应使用 NewRequestWithContext 或 req.WithContext。如果第三方 API 没有 context 参数，就不能假设它会因请求取消而自动返回，需要在边界上补一层可停止的适配。

让下游调用和自建 goroutine 可取消

对于自己写的循环或后台协作任务，要把取消点写进等待逻辑。select 中至少要有 case ，并且收到信号后真正执行 return 或停止向结果通道发送。仅仅在另一个 goroutine 里打印“收到取消”仍然不能让 Handler 结束。

func collect(ctx context.Context, jobs 

示例中的 done 不是为了“杀掉” goroutine，而是为了让 goroutine 自己观察取消并退出后，Handler 再返回。生产代码还要确认结果通道的关闭策略、发送方数量以及是否需要关闭下游资源；如果这些关系没有定义清楚，修复一个阻塞点后仍可能在另一个点挂住。

用退出路径和资源清单复查

可以按下面的顺序做一次小范围排查，不需要先改服务器参数：

1. 请求边界：确认日志中的取消来自客户端断开、请求超时，还是业务自己派生的子 context；不要把不同原因都当成 Handler 已返回。
2. 阻塞调用：逐个检查 HTTP、数据库、队列和文件操作是否接受并使用 ctx。不接受 context 的调用是最值得优先隔离的点。
3. 自建循环：检查每个 for、select、channel 发送和接收是否有取消分支；CPU 密集循环还应定期检查 ctx.Err()。
4. 响应边界：Handler 返回后，不要让后台 goroutine 继续写 ResponseWriter。如果业务必须异步处理，应把它移出请求生命周期，并明确独立的生命周期和资源上限。

还要注意服务关闭场景：Server.Shutdown 的语义是优雅等待活跃连接结束，并不会替你中断所有正在执行的 Handler。需要在停机时主动终止业务工作时，应给应用任务另设服务级 context，并让 Handler 和下游同时监听它；不能只期待 HTTP 请求 context 自动完成这件事。

常见问题

为什么 ctx.Err() 已经是 canceled，函数还没有退出？

Err 只报告取消原因，不负责抢占当前函数。函数必须在循环、channel 或下游调用处观察信号并返回。

把 r.Context() 换成 context.Background() 能解决吗？

不能。这会切断请求取消传播，通常只会让下游继续工作更久。只有明确脱离请求生命周期的独立任务，才应设计自己的根 context。

Handler 里启动 goroutine 后直接 return 有什么风险？

后台任务可能继续占用资源、发送到没人接收的 channel，或在响应生命周期结束后写入 ResponseWriter。要么在请求 context 下协作停止并等待，要么把任务交给独立的任务系统。

客户端断开后还能写 HTTP 响应吗？

不能把写响应当成可靠的成功动作。客户端已断开时，写入可能报错，也可能只是没有实际接收者；先停止无意义工作，再按服务端日志处理错误。

所以，排查“context 已取消但 Handler 不退出”时，真正要找的是最后一个没有取消路径的阻塞点。把请求 context 沿着调用链传下去，让循环和 goroutine 协作停止，并在返回前完成资源收尾，Handler 才会从“收到通知”走到“真正返回”。