Go 怎样派生不继承取消信号的上下文

处理 HTTP 请求时，客户端断开、上游超时或请求处理器主动取消，都会让请求上下文的取消信号向下游传播。问题在于：写审计记录、提交收尾事件这类工作，有时还需要请求里的租户或追踪值，却不应该因为请求已经结束就立刻丢弃。

需要“保留请求值，但不继承父级取消”时使用 context.WithoutCancel(parent)。它会去掉截止时间和取消通道，所以脱离后的任务必须再用 context.WithTimeout 或 context.WithDeadline 设置自己的结束边界。

Go 怎样拆开取消信号、截止时间和值

普通的派生上下文会沿着父链继承取消关系。父上下文一旦结束，子上下文也会结束；这正是请求调用数据库、下游 HTTP 服务时需要的语义。WithoutCancel 是一个有意切断取消传播的派生节点，不能把它理解成“复制一份完整上下文”。

这组差异解释了一个常见误判：脱离取消不等于继承原来的剩余时间。官方定义明确说明，返回上下文没有 Deadline，Done 也是 nil。若后续函数只依赖 ctx.Done() 来结束等待，它可能一直等下去。

用 WithoutCancel 保留请求值，再给任务设置自己的时限

最稳妥的写法是分两层：第一层切断父级取消，第二层马上建立一个新的可取消上下文。下面的例子模拟请求结束后写审计事件，任务仍能读取租户值，但最多只等待两秒。

package main

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

type tenantKey struct{}

func auditContext(parent context.Context) (context.Context, context.CancelFunc) {
	// WithoutCancel 只隔离父级取消；这里再设两秒，避免任务无限等待。
	base := context.WithoutCancel(parent)
	return context.WithTimeout(base, 2*time.Second)
}

func writeAudit(parent context.Context) error {
	ctx, cancel := auditContext(parent)
	defer cancel() // 及时释放定时器和子上下文引用。

	tenant, _ := ctx.Value(tenantKey{}).(string)
	select {
	case 

如果父请求在 writeAudit 开始后立即取消，ctx.Value(tenantKey{}) 仍可取到租户值；但父级的 Done 不会关闭这个派生上下文。两秒超时来自新的 WithTimeout，因此收尾任务仍有确定的退出点。

哪些工作应该脱离请求取消，哪些不应该

选择的关键不是“后台任务是否重要”，而是任务的结果是否仍属于原请求的实时响应。数据库写入、库存扣减、权限判断和下游调用通常必须遵守原请求的取消边界；绕过取消可能让调用方已经失败后，核心状态仍继续变化。

更合适的对象是可重复、可补偿或允许延迟完成的工作，例如记录请求结束原因、写入不可丢失的审计队列、刷新一次本地指标。即使这些工作脱离了父级取消，也要设置任务级超时、队列容量和重试策略，不能用 WithoutCancel 代替任务治理。

常见问题：WithoutCancel 的几个边界

WithoutCancel 会保留父上下文的超时吗？

不会。返回值没有 Deadline，也不会因为父级 deadline 到期而结束。需要时应在它外面重新包一层 WithTimeout。

WithoutCancel 能让原请求的数据库操作继续吗？

技术上可以把它传入调用，但通常不应该这样做。原请求的核心业务应保留取消语义，只有明确属于请求结束后的收尾工作才考虑隔离。

为什么 select 里的

因为 Done() 返回 nil。对 nil channel 的接收分支会永久阻塞，必须同时提供任务自己的超时、结果或关闭信号。

把 WithoutCancel 看成“取消语义的边界工具”，再配合独立的超时和资源策略，才能既保留必要的请求值，又避免后台任务失控。