Go context.WithoutCancel 怎么取消父任务影响但保留请求值

我第一次把 HTTP 请求里的后台收尾任务单独放进 goroutine 时，遇到的现象很典型：请求一结束，原来的 Context 也被取消了，审计日志还没写完就提前返回。换成 context.Background() 虽然能继续执行，却又丢掉了请求 ID 这类追踪值。

context.WithoutCancel 正好解决“保留 Value，但不继承父取消”的这一小块问题。它返回的派生 Context 不会因为父级取消而结束，Done() 为 nil，没有 Deadline，Err() 和 Cause() 也返回空值。不过它不会替后台任务自动设置寿命，所以实际使用时通常还要在外层再加一个自己的 WithTimeout。

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

一、先分清 WithoutCancel 继承了什么

Context 的继承关系容易被“派生”两个字误导。普通的 WithCancel、WithTimeout 会继续观察父级的取消信号；WithoutCancel 则只保留 Value 的查找关系，把取消和截止时间这一侧的继承切断。它从 Go 1.21 开始提供。

因此下面几件事要一起记：父 Context 取消后，新的 Context 不会收到取消；调用它的 Done() 得到的是 nil；Deadline() 没有有效截止时间；Err() 和 context.Cause() 都是 nil。但通过 Value 查找父级保存的值仍然有效。

二、为后台收尾重新建立自己的时限

我更推荐把它当成“切断父取消”这一个动作，而不是把它当成后台任务的完整生命周期方案。比如请求结束后写一条短审计记录，可以保留 request ID，但应当给这条记录单独的超时。

type requestIDKey struct{}

func startAudit(parent context.Context, event string) {
	// 先断开父请求的取消链，但只保留读取请求元数据的能力。
	base := context.WithoutCancel(parent)
	// 脱离父级后没有截止时间，必须为后台任务建立自己的上限。
	jobCtx, cancel := context.WithTimeout(base, 3*time.Second)
	defer cancel()

	go func() {
		// 任务内部仍可读取 request ID，但所有 I/O 都使用 jobCtx。
		requestID, _ := jobCtx.Value(requestIDKey{}).(string)
		if err := writeAudit(jobCtx, requestID, event); err != nil {
			// 超时或存储错误只影响收尾任务，不回写已经结束的请求。
			log.Printf("audit failed: %v", err)
		}
	}()
}

这里的关键不是“开一个 goroutine 就能后台执行”，而是把生命周期边界写清楚：父请求负责触发，jobCtx 负责限制收尾时间，底层写入函数必须继续接收并使用这个 Context。否则即使外层设置了超时，内部 I/O 仍可能无限等待。

三、请求值可以保留，但不要把请求本身带走

Value 适合放 request ID、租户标识这类小型、只读的请求元数据。它不适合替代函数参数，也不适合存放可变业务对象、用户提交的大段内容或需要长期持有的资源。WithoutCancel 只是让派生 Context 还能向父级查值，并不意味着这些值可以脱离业务生命周期永久保存。

func handler(w http.ResponseWriter, r *http.Request) {
	// 请求进入时写入短小的追踪元数据，供同一次调用链读取。
	ctx := context.WithValue(r.Context(), requestIDKey{}, "req-2026")

	// 业务响应完成后只传递收尾所需的 Context，不传递整个 Request。
	startAudit(ctx, "response-written")
	w.WriteHeader(http.StatusAccepted)
}

如果后台任务还需要用户输入、文件句柄或数据库事务，最好把这些依赖显式作为函数参数，并在任务结束时释放。Context 的职责是传递取消、截止时间和请求范围值，不是一个通用的后台任务容器。

四、按检查点选择 Context API

实际落地时，我会先问“这项工作是否应该随着请求结束而停止”。如果答案是应该，就继续使用原始 Context；如果只需要在请求结束后完成一小段收尾，再用 WithoutCancel 切断父取消并重新加独立时限。若任务本来就不需要任何请求值，直接从更高层传入独立 Context 往往更直白。

我的经验是：WithoutCancel 适合边界很清晰的“请求已经结束，但还要做一点收尾”的场景。它不是取消机制的替代品，也不是把请求上下文永久升级成全局上下文的捷径。

相关问题

WithoutCancel 会保留父 Context 的 Deadline 吗？

不会。官方定义明确说明它返回无 Deadline 的 Context，所以脱离父级后必须自行设置后台任务的超时或截止时间。

为什么不用 context.Background()？

如果后台任务不需要任何请求值，Background 可以作为独立根 Context；但需要 request ID 等元数据时，WithoutCancel 能保留 Value 查找，同时把取消边界拆开。

WithoutCancel 能让任务永远运行吗？

它只是让父级取消不再终止派生 Context，并不应该被用来制造无限期任务。给后台工作设置明确的 WithTimeout，并在任务结束时释放资源。