Go context.WithoutCancel 怎么保留值并断开取消链

context.WithoutCancel(parent) 会创建一个仍然指向父 Context 的派生 Context，因此父链上的请求值还能通过 Value 查到；但它不再继承父 Context 的取消与截止时间。返回值的 Done() 是 nil，没有 Deadline，Err() 和 context.Cause 也都返回 nil。

它适合“请求已经结束，但还要用原请求的 trace_id 做一次短暂收尾”的场景。正确姿势不是无限期分离，而是先用 WithoutCancel 断开旧取消链，再用 WithTimeout 给后台任务建立新的时间边界。

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

先看 WithoutCancel 到底保留和移除了什么

WithoutCancel 从 Go 1.21 加入标准库。它的返回值与父 Context 有关系，但这个关系只保留值查询，不保留取消传播。可以先用一张表建立准确预期：

最小示例可以同时验证“值还在”和“取消已断开”：

package main

import (
	"context"
	"fmt"
)

// traceKey 使用自定义类型，避免与其他包的键发生碰撞。
type traceKey struct{}

func main() {
	parent, cancelParent := context.WithCancel(context.Background())
	parent = context.WithValue(parent, traceKey{}, "trace-2026")

	// detached 仍然沿父链查询值，但不会接收父级取消信号。
	detached := context.WithoutCancel(parent)
	cancelParent()

	fmt.Println(detached.Value(traceKey{}))
	fmt.Println(detached.Done() == nil)
	fmt.Println(detached.Err())
}

这里不要把 Context 值当作通用参数袋。Go 官方文档建议，Value 只用于跨 API 边界传递的请求作用域数据；批次大小、重试次数、文件名这类业务参数应显式传入函数。

值不是复制，而是继续沿父链查询

理解这一点很重要：WithoutCancel 不会把父 Context 里的键值复制到一张新 map。标准库实现持有父 Context，并在 Value 查询时继续向父链查找。这样既保留了请求元数据，又让取消相关方法表现为一个新的边界。

因此，Context 中的值如果指向 map、切片或自定义对象，它们仍然是原对象。后台 goroutine 与请求处理 goroutine 并发访问这些可变对象时，仍要自行同步。WithoutCancel 解决的是取消传播，不会自动提供数据副本或并发安全。

// auditFields 是显式复制后的快照，适合后台任务读取。
auditFields := map[string]string{
	"trace_id": traceID,
	"user_id":  userID,
}

// 不要假设 WithoutCancel 会复制 map；业务数据快照应由调用方明确创建。
_ = auditFields

在 HTTP 请求结束后创建有上限的后台任务

下面用“响应返回后写一条审计记录”做完整示例。请求 Context 通常会在处理函数返回后取消，如果直接把 r.Context() 交给后台 goroutine，审计写入可能立刻得到 context canceled。如果直接换成 context.Background()，又会丢掉 trace_id。WithoutCancel 正好放在这两个需求之间。

package audit

import (
	"context"
	"log"
	"net/http"
	"time"
)

// traceKey 只承载请求作用域的追踪标识。
type traceKey struct{}

func Handler(w http.ResponseWriter, r *http.Request) {
	// 先断开请求取消链，但保留父链上的 trace_id 等值。
	detached := context.WithoutCancel(r.Context())

	go func() {
		// 后台任务重新建立 5 秒超时，避免无限运行。
		taskCtx, cancel := context.WithTimeout(detached, 5*time.Second)
		defer cancel() // 任务结束时及时释放计时器等资源。

		if err := writeAudit(taskCtx); err != nil {
			log.Printf("写入审计记录失败: %v", err)
		}
	}()

	w.WriteHeader(http.StatusAccepted)
}

func writeAudit(ctx context.Context) error {
	// 实际项目可把 ctx 传给支持 Context 的数据库或 HTTP 调用。
	_ = ctx.Value(traceKey{})
	return nil
}

每一步的核对点很明确：处理函数返回后，后台任务不应因为请求取消立即停止；后台调用仍能读取 trace_id；运行超过 5 秒时，taskCtx.Done() 会关闭，taskCtx.Err() 返回 context.DeadlineExceeded。

为什么不能直接等待 WithoutCancel 的 Done

WithoutCancel 返回 Context 的 Done() 是 nil channel。Go 的 select 会禁用 nil channel 对应的 case，这通常很方便；但如果代码直接执行 ，就会永久阻塞。

func wait(ctx context.Context) {
	select {
	case 

如果函数的设计前提是“一定会收到 ctx.Done()”，就不应该直接传入裸的 WithoutCancel Context。先套一层 WithTimeout 或 WithCancel，让新的 Context 获得非 nil 的 Done channel。

异常处理与清理边界

使用 WithoutCancel 时，我会逐项检查下面四个边界：

1. 后台任务必须有上限：优先用 WithTimeout，并根据下游服务的实际耗时设置期限。
2. 创建者负责 cancel：拿到 CancelFunc 后立即安排 defer cancel()，不要只依赖超时自然到期。
3. 业务参数显式传递：Context 值保留给 trace_id、认证信息等请求作用域元数据，任务负载使用函数参数或任务结构体。
4. 关键任务不要只靠裸 goroutine：进程退出时内存中的后台任务仍可能丢失。必须可靠完成的工作更适合持久化队列、任务表或独立 worker。

如果父 Context 为 nil，context.WithoutCancel(nil) 会 panic，因此调用链仍要保证传入非 nil Context。通常函数参数应该直接要求 context.Context，不要把 nil 当作“没有 Context”。

常见问题速查

WithoutCancel 和 context.Background 有什么区别？

两者都不会被请求取消，也没有默认截止时间，但 Background 是空根 Context，不包含请求链上的值；WithoutCancel(parent) 仍可从 parent 查询值。

父 Context 取消后，原来的值会消失吗？

不会因为取消本身而消失。WithoutCancel 仍沿父链执行 Value 查询。不过值引用的对象是否仍安全可用，取决于对象自己的生命周期和并发保护。

能不能只用 WithoutCancel，不加 WithTimeout？

语法上可以，但后台任务没有取消和截止边界，容易在下游卡住时长期占用资源。短暂收尾任务通常应该补一层 WithTimeout。

WithoutCancel 会保留父 Context 的取消原因吗？

不会。官方定义明确说明，对其返回值调用 context.Cause 得到 nil。需要记录父取消原因时，应在断开前显式读取并作为普通数据保存。

总结起来，WithoutCancel 做的是“保留值查询链，切断取消与截止时间链”。把它与新的 WithTimeout 组合，才能得到既保留请求元数据、又不会无限运行的后台任务 Context。

参考资料：

• https://pkg.go.dev/context#WithoutCancel
• https://go.dev/src/context/context.go
• https://go.dev/blog/context
• https://go.dev/blog/context-and-structs