Go context 怎样给后台任务设置独立生命周期

在 HTTP 处理器里启动异步任务时，最容易踩到的坑是：请求一结束，后台任务也跟着收到取消信号。如果这个任务需要在客户端断开后继续完成，推荐的组合是 context.WithoutCancel 加 context.WithTimeout：前者切断请求的取消和期限，后者为后台工作重新设置一个明确的生命周期。

官方地址：https://pkg.go.dev/context

不要直接把请求上下文交给后台任务，也不要把所有任务都换成永久有效的 context.Background()。先用 WithoutCancel 保留需要的上下文值，再派生一个有超时的任务上下文，才能同时处理“请求已结束”和“任务不能无限运行”这两个问题。

先分清两个生命周期

请求上下文代表一次请求。客户端断开连接、处理器返回或上游主动取消时，它的 Done() 会关闭，依赖它的派生上下文也会收到取消信号。这种行为对查询、下游 HTTP 调用和流式响应很有用，因为请求已经没有必要继续消耗资源。

但发送审计记录、整理导出文件、刷新异步索引这类工作，可能需要在响应返回后继续几秒。它们不应该继续继承请求的取消信号，却仍可能需要请求中的租户标识、链路标识或任务参数。这里需要的是“独立生命周期”，不是“永不取消”。

用 WithoutCancel 脱离请求取消

WithoutCancel(parent) 返回一个指向父上下文、但不随父上下文取消的派生上下文。它仍能通过 Value 读取父上下文中的值；同时它没有父级的 Deadline，Done() 为 nil，Err() 和 Cause() 也不会因为父级取消而返回错误。该函数从 Go 1.21 开始提供。

因此，下面这段代码只完成了“解除请求取消”，并没有完成“给任务设定期限”。如果把 detached 直接传给可能阻塞的任务，任务可能一直等待。

func detachFromRequest(parent context.Context) context.Context {
	// 保留 parent 的 Value，但不继承请求取消、截止时间和 Err。
	return context.WithoutCancel(parent)
}

在脱离后重新设置任务期限

更完整的做法是在脱离后的上下文上调用 WithTimeout。这样任务不会因为请求提前结束而被取消，但会在自己的超时时间到达后停止。创建出的取消函数要在拥有该上下文的函数中调用，以释放计时器等资源。

package main

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

type requestIDKey struct{}

func runExport(ctx context.Context) error {
	// 用 Done 监听任务自己的截止时间，避免后台工作无限等待。
	select {
	case 

这里的关键顺序是：请求上下文 → WithoutCancel → WithTimeout。如果顺序反过来，先从请求上下文创建了带超时的上下文，再对它调用 WithoutCancel，父级的截止时间仍会被切断，最终只留下后一个独立上下文的语义；虽然也能工作，但更难从代码结构上看出“任务期限从哪里开始”。

请求值可以保留，但请求对象不要搬过去

WithoutCancel 会继续委托 Value 查询，所以适合保留不可变的请求标识。它并不会把请求处理器、响应写入器或数据库事务变成后台任务的安全依赖。后台函数应该接收明确的任务参数，并重新获取适合异步执行的资源。

func enqueueExport(requestCtx context.Context, fileID string) {
	// 只复制需要的值语义，任务参数 fileID 单独传递。
	taskCtx, cancel := context.WithTimeout(
		context.WithoutCancel(requestCtx),
		30*time.Second,
	)

	go func(ctx context.Context, id string) {
		defer cancel() // 无论成功还是超时，都释放任务上下文资源。
		if err := exportFile(ctx, id); err != nil {
			// 真实项目中应写入异步任务日志或失败队列，而不是写回已结束的响应。
			fmt.Println("export failed:", err)
		}
	}(taskCtx, fileID)
}

如果任务需要使用用户身份、租户号或链路 ID，可以把这些值设计成自定义 key 放在上下文中；如果任务需要请求体、http.ResponseWriter 或一个只允许请求期间使用的事务对象，则应在启动任务前提取必要数据，不能依赖它们在请求返回后仍然有效。

三种写法的差异

对请求触发的短时后台工作，第三种写法通常最容易解释和回收。它把“是否继续”与“最多运行多久”拆成两个明确决策，也能避免使用 Background() 后丢失请求范围值。

使用时要留意的边界

• WithoutCancel 本身没有 Done：必须在它之上派生 WithTimeout、WithDeadline 或 WithCancel，否则下游等待取消的逻辑没有结束信号。
• 超时不是可靠投递：如果任务不能丢失，应使用持久化队列或任务表；context 只负责通知当前执行单元停止。
• 不要写回原响应：处理器返回后，ResponseWriter 的生命周期已经结束，后台任务应写日志、状态表或队列。
• 检查错误来源：任务超时通常会从 ctx.Err() 得到 context.DeadlineExceeded；调用方取消则通常是 context.Canceled。不要把所有失败都归因于请求取消。
• 控制并发数量：每个请求都启动一个 goroutine 可能形成突发负载，生产环境仍需要队列、信号量或固定 worker 池。

结论

当后台任务需要越过请求结束点继续执行时，优先使用 context.WithoutCancel(requestCtx)，再用 context.WithTimeout 或 WithDeadline 建立新的结束条件。这样既不会让客户端断开直接杀掉任务，也不会把任务变成无期限 goroutine。最后把请求值、任务参数和持久化可靠性分别处理，context 只承担取消与期限传播的职责。

相关问题

WithoutCancel 会丢失 context.Value 吗？不会，它仍指向父上下文并可读取值，但不会继承父级取消、Deadline 和 Err。

为什么不直接使用 context.Background？Background 不依赖请求，也没有请求值；对于需要链路或租户信息的短时任务，WithoutCancel 更能表达真实边界。

任务必须一定完成时还能只用 context 吗？不能。context 只提供当前执行单元的取消通知，可靠完成需要队列、持久化任务状态和可重试机制。