Go context deadline 已过但请求仍执行的边界

Go 里看到 context deadline exceeded，并不等于所有相关代码已经停止。deadline 到期后，派生 context 会关闭 Done()，Err() 会返回 context.DeadlineExceeded；真正能否停下来，取决于工作函数有没有继续传递这个 context、有没有在合适的位置观察取消信号，以及底层驱动是否支持取消。

排查“超时了请求还在执行”时，先把“取消信号已产生”和“业务 goroutine 已退出”分成两件事。前者由 context 保证，后者必须由调用链和驱动共同完成。

官方文档：https://pkg.go.dev/context

取消数据库操作：https://go.dev/doc/database/cancel-operations

先分清 deadline、Done 和 Err 的职责

context.WithTimeout 或 context.WithDeadline 创建的是一个带截止时间的派生 context。截止时间到达后，运行时负责关闭 Done()，之后调用 Err() 可以得到 DeadlineExceeded。这是一条协作式取消协议，不是对 goroutine 的强制杀死指令。

另外，取消函数不会等待工作结束，所以即使调用了 cancel()，也不能把它当成“任务已经退出”的确认。需要知道任务是否结束时，应让工作函数返回结果，或通过明确的完成通道、错误组和退出日志建立可观察的结束点。

检查派生 context 是否传到了工作函数

最常见的错误不是 context 机制失效，而是超时 context 创建后没有沿调用链传下去。例如入口使用了 ctx，内部函数却重新使用 context.Background()，或者把旧的父 context 传给了实际请求。

package main

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

func load(ctx context.Context) error {
	// 工作函数必须接收调用方的派生 context，不能在这里重新创建 Background。
	select {
	case 

如果把 load(ctx) 改成 load(context.Background())，入口的 deadline 仍会按时到期，但实际工作已经脱离了这条取消链。检查这类问题时，沿着“入口 → 服务层 → 驱动层”逐个确认 context 参数，比只盯着超时日志更有效。

在循环和阻塞点设置取消检查

传入 context 只是建立了信号通道；自定义计算必须主动读取这个通道。长循环至少要在每轮或每批工作前检查一次，可能永久阻塞的等待则要把 ctx.Done() 放进同一个 select。

func process(ctx context.Context, jobs 

这里的检查点不是“让 deadline 变得更强”，而是给业务代码一个明确的退出机会。若 doOneJob 内部又执行很长的纯 CPU 计算，它仍然需要拆成可检查的小段；若它调用阻塞 I/O，则应改用接收 context 的 API。

让 HTTP 或数据库驱动接收 context

标准库和许多驱动提供了 context 版本的入口。HTTP 请求可以用 http.NewRequestWithContext 绑定 context，数据库调用则应优先使用 QueryContext、ExecContext 等方法。这样超时信号至少能抵达客户端或驱动的本地等待。

func fetch(ctx context.Context, client *http.Client, endpoint string) error {
	// 把同一个 ctx 绑定到请求，避免只给外层函数设置超时。
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
	if err != nil {
		return err
	}
	resp, err := client.Do(req)
	if err != nil {
		// 请求被取消时通常可以从 ctx.Err() 判断超时或主动取消。
		if ctx.Err() != nil {
			return ctx.Err()
		}
		return err
	}
	defer resp.Body.Close()
	return nil
}

这仍然有一个重要边界：客户端取消的是自己能控制的请求等待和连接，不会自动撤销远端已经开始的业务处理。服务端若要尽早停止，也必须把它自己的请求 context 传到数据库、RPC 或内部循环；跨服务场景还要设计幂等、取消传播和结果回收。

处理 goroutine 生命周期与资源收尾

如果日志只打印了 ctx.Err() 就认为请求结束，容易把“调用方放弃等待”和“后台工作退出”混为一谈。后台 goroutine 应该有明确的返回路径，并且资源释放要放在它自己的生命周期里。

func start(ctx context.Context, done chan

这段模式并不能替代对 work 的检查。如果 work 完全忽略 context，外层超时后 goroutine 依旧可能存在。生产代码还要根据业务选择错误组、任务队列或显式的停止协议，确保结束、重试和资源关闭都能被观察。

一张清单定位“超时后仍执行”

1. 确认超时的是哪个派生 context，并记录 Deadline()、Done() 和 Err() 的对应关系。
2. 沿调用链检查 context 是否被替换成 Background()、TODO() 或旧的父 context。
3. 检查长循环、channel 等待、锁等待和 I/O 是否有取消检查点。
4. 确认 HTTP、数据库、RPC 驱动是否使用了 context 版本的入口。
5. 区分本地调用返回、服务端业务停止和后台 goroutine 退出，这三者不一定同时发生。
6. 用显式结束信号和资源收尾记录真正完成时间，不用 deadline 日志代替完成回执。

常见问题

deadline 过期后还能继续读取 ctx.Value 吗？

可以读取，但 Value 不是取消机制。是否退出要看 Done 和 Err，不要用业务值代替取消信号。

调用 cancel() 后为什么 goroutine 还在？

CancelFunc 只发出取消信号，不等待工作停止。goroutine 必须主动观察 context，或者调用支持 context 的阻塞 API 才能退出。

HTTP 客户端超时了，服务端一定停止了吗？

不一定。客户端可以放弃等待，但服务端已经提交的任务可能继续执行。需要跨服务停止时，应在服务端传播请求 context，并用幂等和任务状态设计补偿。

总结一下：Go context deadline 的职责是广播取消和截止时间，不是强制终止执行。要让“超时后仍执行”真正消失，必须同时做到 context 传递、检查点覆盖、驱动支持和 goroutine 生命周期可观察。