Go context 怎样复制值但不继承取消信号

HTTP 请求结束后，日志落盘、审计写入或消息投递有时还要读取请求里的 request_id，但又不能因为请求 context 被取消就立刻中断。这个场景不要手写一个“复制 Value 的 context”，直接使用 context.WithoutCancel(ctx)：它继续沿用父 context 的值查找链，却不继承取消信号、deadline 或错误。

要保留请求值、切断父 context 的取消影响，使用 context.WithoutCancel；脱钩后必须再加自己的超时或退出条件，不能把任务变成无限期后台 goroutine。

context.WithoutCancel 怎样保留值但切断取消链

普通派生 context 会形成一棵取消树：父节点取消后，子节点也会收到信号。WithoutCancel 仍然指向父 context，所以 Value 可以继续向上查找；但它把取消相关的方法改成“无边界”状态：没有 deadline，Done() 返回 nil，Err() 返回 nil，context.Cause 也返回 nil。

示例中的 key 应使用包内私有类型，避免不同包用同一个字符串造成碰撞。下面的代码只演示派生关系，真正的收尾函数仍应处理错误并尽快返回。

package main

import (
    "context"
    "fmt"
)

type requestIDKey struct{}

func main() {
    // 父 context 携带请求级值；取消通常由请求生命周期触发。
    parent := context.WithValue(context.Background(), requestIDKey{}, "req-7f3a")
    detached := context.WithoutCancel(parent)

    // 值仍能读取，但脱钩 context 不再继承父 context 的取消状态。
    fmt.Println(detached.Value(requestIDKey{}))
    fmt.Println(detached.Done() == nil, detached.Err() == nil)
}

脱钩后怎样补上独立超时

切断取消链并不等于放弃生命周期控制。由于 Done() 是 nil，直接把 detached 传给一个只等待 ctx.Done() 的循环，可能永远等不到退出信号。更稳妥的写法是在它上面重新建立一个独立的超时边界：

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

func enqueueAudit(ctx context.Context, audit func(context.Context) error) error {
    // 收尾任务需要 request_id 等值，但不应被请求取消直接打断。
    detached := context.WithoutCancel(ctx)

    // 脱钩后自行设置上限，避免队列或网络调用无限等待。
    taskCtx, cancel := context.WithTimeout(detached, 5*time.Second)
    defer cancel() // 释放计时器和子 context 的引用。

    if err := audit(taskCtx); err != nil {
        return fmt.Errorf("audit: %w", err)
    }
    return nil
}

这里的 5 秒只是示例参数，生产环境应按审计落库、消息发送或远程接口的实际 SLA 设置。若任务本身不需要请求值，直接用 context.Background() 再加超时更容易表达意图。

这几个 context 边界怎么选

还要留意值的内容。身份、授权信息或大对象一旦被带入长期队列，可能扩大数据暴露面和内存占用。脱钩 context 最好只在短调用链中使用，并把需要的字段转换成明确的任务参数。

常见问题

WithoutCancel 会复制一份 Value 数据吗？

不会。它返回指向父 context 的派生 context，读取值时仍沿父链查找，不是深拷贝。若值是可变对象，仍要遵守并发访问规则。

WithoutCancel 能读取父 context 的 deadline 吗？

不能。它返回的 context 没有 deadline；如果任务需要期限，使用 WithTimeout 或 WithDeadline 重新设置。

什么时候应该继续传原来的 ctx？

只要工作属于请求本身，或者请求取消就应该停止，就继续传原 ctx。只有明确属于请求结束后的短收尾，才考虑脱钩。