context没有调用cancel导致资源泄漏怎么办

在 Go 里，context.WithCancel、context.WithTimeout 和 context.WithDeadline 返回的第二个值不是可有可无的“结束按钮”。如果派生出的 context 已经不再使用，却一直没有调用 cancel，父 context 会继续持有它，相关子节点也可能继续被保留；带截止时间的 context 还可能继续持有定时器资源。

最稳妥的做法是：创建派生 context 后立刻安排 defer cancel()；如果它在循环或异步任务中创建，就把 cancel 的调用点放到本次任务真正结束的位置。cancel 释放的是派生 context 的生命周期资源，不等于自动杀掉所有 goroutine。

这也是 Go 官方文档建议尽快调用 cancel 的原因。真正能否停止数据库、HTTP 或自定义工作，还取决于下游是否接收并尊重同一个 context。

不调用 cancel 到底会泄漏什么

WithCancel 创建的是带有新 Done 通道的派生 context。调用返回的 CancelFunc 时，派生 context 会被标记为取消，父节点对它的引用会解除，子节点也会收到取消信号。若迟迟不调用，派生 context 可能一直留在父节点的子集合中，直到父节点最终取消。

对 WithTimeout 或 WithDeadline 来说，额外的截止时间还涉及定时器。即使超时最终会触发取消，函数提前返回后仍应主动调用 cancel，让“不再需要这个 context”这件事立即生效。这里的“资源泄漏”更准确地说是生命周期资源被延长，不应直接等同于每次都会出现一个永久 goroutine。

如果代码只是把 context 传给一个不检查 ctx.Done() 的自定义循环，或者底层 API 根本不支持取消，那么调用 cancel 也不会凭空终止那段工作；它只能把取消信号发出去。排查时要同时看派生 context 的释放和下游的响应。

创建后立即绑定 cancel，默认写法最安全

短函数里应在创建派生 context 的下一行安排 cancel。这样无论后面是正常返回、参数错误还是下游调用失败，函数退出时都能释放本次派生 context。

func loadProfile(ctx context.Context, db *sql.DB, id int64) (*Profile, error) {
	// 超时只覆盖本次查询；函数结束时立即释放派生 context 的资源。
	queryCtx, cancel := context.WithTimeout(ctx, 3*time.Second)
	defer cancel()

	// QueryContext 接收同一个 context，数据库操作才能感知取消或超时。
	row := db.QueryRowContext(queryCtx, `SELECT id, name FROM profiles WHERE id = ?`, id)
	var p Profile
	if err := row.Scan(&p.ID, &p.Name); err != nil {
		// 错误返回前不需要手写第二处 cancel，defer 会负责收尾。
		return nil, err
	}
	return &p, nil
}

这里的关键不是把超时时间写成 3 秒，而是让派生 context 与一次查询的生命周期一致。若外层请求先结束，父 context 取消会向下传播；若查询先结束，函数返回时的 defer cancel() 会主动释放本次派生资源。

把取消信号传到真正工作的边界

只写 cancel() 还不够。自定义循环需要监听 ctx.Done()，标准库调用则优先选带 Context 的版本，例如 QueryContext、ExecContext 或 http.NewRequestWithContext。

func consume(ctx context.Context, jobs 

数据库驱动也有能力边界：database/sql 会把 context 传给驱动，但不支持 context 取消的驱动可能要等查询完成后才返回。因此要把“已发出取消信号”和“底层操作已停止”分开判断。

循环和异步任务要重新安排释放点

在一次短函数里使用 defer cancel() 很合适，但不要在一个很长的循环里为每个元素创建 context 后都 defer 到外层函数返回。这样每轮的释放点会被推迟，短任务积多后就可能造成不必要的资源占用。

func processBatch(parent context.Context, jobs []Job) error {
	for _, job := range jobs {
		if err := processOne(parent, job); err != nil {
			// 单个任务失败时结束批处理，上一轮的 cancel 已经完成。
			return err
		}
	}
	return nil
}

func processOne(parent context.Context, job Job) error {
	// 把每轮工作放进独立函数，让 defer 在本轮返回时执行。
	ctx, cancel := context.WithTimeout(parent, time.Second)
	defer cancel()
	return handle(ctx, job)
}

异步任务则要先明确所有权：如果 worker 继续使用派生 context，就不能在启动 goroutine 的外层函数返回时立刻 cancel；应由 worker 在工作结束时调用，或者由一个明确的任务管理器持有 cancel。反过来，如果外层函数已经不再需要这项工作，就应取消它并让 worker 监听 ctx.Done() 后退出。

用 go vet 和清单收尾

可以先运行静态检查，捕捉 CancelFunc 没有在所有控制流路径使用的常见问题：

# 检查 CancelFunc 是否在控制流中被正确使用。
go vet ./...

提交前再按下面的顺序看一遍：

• 每个 WithCancel、WithTimeout、WithDeadline 是否都有明确的 cancel 所有者。
• 短函数是否在创建后立即安排了 defer cancel()，长循环是否把每轮工作封装成小函数。
• 下游是否真正接收 context，并在自己的循环或 API 中处理取消；cancel 不会替代 rows.Close()、HTTP 响应体关闭等独立资源清理。
• 超时、主动取消和正常结束时，错误是否能区分 context.DeadlineExceeded、context.Canceled 与业务错误。

一句话总结：cancel 的职责是结束派生 context 的生命周期，业务代码还必须把取消信号接到实际工作上。默认采用“创建即绑定、返回即释放、下游显式监听”，再为循环和异步任务单独设计所有权，就能避免大多数遗漏。

常见问题

父 context 最终一定会取消，还需要调用 cancel 吗？

需要。父节点何时取消通常比当前函数返回晚，主动调用 cancel 能尽早解除引用并停止相关定时器；它也能表达“本次工作已经结束”。

调用 cancel 会自动结束 goroutine 吗？

不会。goroutine 必须读取 ctx.Done() 或调用支持 context 的 API，并在收到取消后返回；没有取消检查的工作仍需单独修复。