Go context.WithoutCancel 脱离父取消的使用边界

context.WithoutCancel(parent) 适合“仍要读取父上下文中的请求值，但任务不应因为请求断开而立刻取消”的短时后台工作。它不是一个自动续命器：返回的上下文没有截止时间，Done() 为 nil，Err() 与 context.Cause() 也始终返回 nil。因此正确边界通常是先脱离父取消，再用 context.WithTimeout 建立当前任务自己的上限。

趋势信号：为什么会出现脱离请求取消的需求

HTTP 客户端断开、反向代理超时或处理函数返回时，请求上下文会被取消。数据库查询、远程调用等主链路工作理应迅速停止，但审计落库、缓存回填、轻量通知等“收尾动作”有时仍需要一个很短的完成窗口。问题的核心不是忽略取消，而是把请求生命周期、异步任务生命周期和服务生命周期明确拆开。

解决的问题：保留值，但不继承父取消

与直接使用 context.Background() 相比，WithoutCancel 的独特价值是仍可通过 Value 读取请求级数据，例如 request ID、trace ID 或已提取的租户标识。它不会复制这些值，而是继续沿父上下文查询，因此引用型数据仍可能被其他代码修改。异步任务真正需要的数据最好先提取到不可变的小结构体中，不要把请求对象、响应写入器或大块缓存塞进上下文。

func DetachedTimeout(parent context.Context, max time.Duration) (context.Context, context.CancelFunc) {
	// 先切断父取消，再为当前任务建立独立截止时间。
	return context.WithTimeout(context.WithoutCancel(parent), max)
}

顺序很重要：如果先对 parent 调用 WithTimeout，再调用 WithoutCancel，后一步仍会移除刚刚设置的截止时间。把“脱离”放在内层，把“重新限时”放在外层，才能得到一个不受请求取消影响、但仍有明确上限的任务上下文。

受益角色：哪些任务适合这种边界

适合的任务通常同时满足四个条件：必须保留少量请求标识；允许在请求结束后继续；执行时间短且有上限；失败可以记录、重试或接受降级。典型例子包括非关键审计、幂等缓存写入、短消息投递和统计采样。下面的写法先复制审计数据，再创建独立的两秒窗口。

type AuditRecord struct {
	RequestID string
	Action    string
}

func launchAudit(parent context.Context, record AuditRecord) {
	detached := context.WithoutCancel(parent)

	go func(ctx context.Context, item AuditRecord) {
		// 后台任务必须有独立上限，避免 nil Done 掩盖无限等待。
		taskCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
		defer cancel()

		if err := writeAudit(taskCtx, item); err != nil {
			// 失败必须可观察，不能在异步分支中悄悄丢失。
			log.Printf("write audit: %v", err)
		}
	}(detached, record)
}

这段代码适合低频且进程退出时允许放弃的任务。若请求量持续增长，应把 AuditRecord 放入有界队列，由固定数量 worker 执行；队列满时要定义拒绝、降级或同步回退策略。

风险：切断取消也会切断保护

第一，返回上下文的 Done() 是 nil。直接从 nil channel 接收会永久阻塞；如果它是 select 中唯一可能触发的分支，代码也无法前进。第二，它没有父截止时间，若下游没有自己的超时，网络或锁等待可能无限延长。第三，父级取消原因不会保留，不能再通过 context.Cause 判断客户端断开还是超时。第四，保留 Value 查询链也意味着父上下文持有的引用可能比请求活得更久。

更重要的是，WithoutCancel 只脱离请求取消，并不会自动接入进程优雅关闭。服务停止时，后台 worker 应由单独的应用级上下文控制，并在 shutdown 阶段停止接单、等待在途任务或按策略终止。

采用路径：从一个 helper 到可控工作队列

可以先把“脱离后立刻限时”封装成统一 helper，并禁止业务代码裸用 WithoutCancel。随后把高频任务迁入有容量上限的队列，让 worker 同时接收任务级超时和应用级关闭信号。事务提交、权限校验、扣款以及必须与请求成败保持一致的操作，不应使用这种方式脱离主链路。

单元测试至少要锁定五个语义：Value 仍可读、Done 为 nil、Err 为 nil、Deadline 不存在、Cause 为 nil。这样升级 Go 版本或重构 helper 时，团队不会误把“脱离父取消”理解成“复制父上下文”。

func TestWithoutCancelKeepsValueButDropsCancellation(t *testing.T) {
	type key string
	parent, cancel := context.WithCancel(
		context.WithValue(context.Background(), key("request-id"), "r-42"),
	)
	detached := context.WithoutCancel(parent)
	cancel()

	// 保留请求值，但取消、截止时间和取消原因都不再传播。
	if detached.Value(key("request-id")) != "r-42" {
		t.Fatal("request value missing")
	}
	if detached.Done() != nil || detached.Err() != nil {
		t.Fatal("unexpected cancellation state")
	}
	if _, ok := detached.Deadline(); ok {
		t.Fatal("unexpected deadline")
	}
	if context.Cause(detached) != nil {
		t.Fatal("unexpected cancellation cause")
	}
}

观察指标：没有数字就无法判断是否越界

上线后至少记录异步任务创建数、完成耗时、独立超时率、失败率、队列深度和丢弃数，并按任务类型区分。若超时率或队列深度持续上升，说明任务已经不再是“短时收尾”，应拆成可靠消息、持久化任务或独立服务。日志应携带复制后的 request ID，但不要依赖已失效的请求对象。

相关问题

WithoutCancel 会复制父上下文的值吗？

不会。它保留父级 Value 查询关系，因此更适合先提取任务必需的不可变字段，再交给异步逻辑。

可以直接用 Background 替代吗？

如果任务完全不需要父级 Value，可以。需要 request ID 等上下文值时，WithoutCancel 更直接，但仍应补独立超时。

数据库事务适合脱离请求取消吗？

通常不适合。事务往往属于请求主链路，客户端取消后继续占用连接和锁会扩大风险；只有经过明确业务设计的补偿或异步任务才应使用独立生命周期。

参考：https://pkg.go.dev/context#WithoutCancel、https://pkg.go.dev/context#Context、https://go.dev/blog/context。官方文档定义了返回上下文的 Deadline、Done、Err、Cause 与 Value 语义。