Go context 怎样只传值但不继承截止时间

Go 中需要保留 Context 的关联值、又不继承父级截止时间时，可以使用 context.WithoutCancel(parent)。但它并非只删除 deadline：父级取消也不再传递。实际工作通常还要在它外面加 context.WithTimeout，为新任务分配独立预算并及时调用 cancel。

这适合一种有明确边界的需求：主任务结束后，一小段补充工作仍需携带请求关联标识。它不意味着请求超时可以随意忽略，也不意味着开一个 goroutine 就具备可靠任务系统。下面采用构造的补充记录场景，没有虚构线上故障、压测数据或上线收益。

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

请求结束与补充工作为什么不能共用期限

设想一个服务调用已经完成主要操作，只剩一段允许独立完成的补充记录。关联值可以继续使用，但父请求剩余的预算可能很少。如果直接将原 Context 交给后续函数，父级取消会影响子任务；如果改用 context.Background()，关联值又不会自动保留。

真正要拆开的是两个责任：哪些元数据可以沿用，以及谁负责停止这段工作。WithoutCancel 解决前一部分与父级生命周期解耦的需要，不会自动回答后一部分。尤其是仍属于请求成功条件的工作，不应仅为了“避免报错”就解除取消。

WithoutCancel 保留了什么又移除了什么

WithoutCancel 从 Go 1.21 起提供。它返回一个派生 Context，仍指向父 Context，普通 Value 查询可以取得父级已有的关联值；父级被取消，不会因此取消这个派生对象。

Done 为 nil 尤其值得注意：直接等待 不会因为父级结束而返回。在 select 中，nil channel 对应的分支不会被选中。因此，不能把 WithoutCancel 当作“有取消能力但暂时没有取消”的普通任务 Context。

先拆开父级取消，再设置任务超时

下面完整示例主动取消父 Context，再构造新的任务 Context。它是教学代码，未在本机编译运行；2 秒只是示例任务预算，不是生产建议值，也不是实际测量结果。

package main

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

// 使用私有键类型，避免和其他包的普通字符串键冲突。
type traceKey struct{}

func runSupplement(parent context.Context, work func(context.Context) error) error {
    if parent == nil || work == nil {
        return fmt.Errorf("上下文与任务函数不能为空")
    }
    // 先解除父级截止时间和取消，再为本次任务增加自己的时间预算。
    valuesOnly := context.WithoutCancel(parent)
    taskCtx, cancel := context.WithTimeout(valuesOnly, 2*time.Second)
    defer cancel() // 即使任务提前结束，也释放本层计时器相关资源。
    return work(taskCtx)
}

func main() {
    base := context.WithValue(context.Background(), traceKey{}, "demo-trace")
    parent, stop := context.WithTimeout(base, time.Second)
    defer stop()
    stop() // 主动模拟父级已经取消，不依赖Sleep制造时序。

    detached := context.WithoutCancel(parent)
    _, hasDeadline := detached.Deadline()
    fmt.Println("父级错误:", parent.Err())
    fmt.Println("关联值:", detached.Value(traceKey{}))
    fmt.Println("继承截止时间:", hasDeadline)
    fmt.Println("Done为nil:", detached.Done() == nil)

    err := runSupplement(parent, func(ctx context.Context) error {
        // 任务应配合取消；真实阻塞操作也必须接收ctx或有自己的中止机制。
        select {
        case 

这里的 valuesOnly 负责保留值查询关系，taskCtx 通过 WithTimeout 得到独立的截止时间，cancel 则由 runSupplement 在任务结束时释放。先 WithoutCancel，再 WithTimeout，顺序表达的是“新的任务预算”，不是延长原请求的截止时间。

读者自行运行时，预期可以观察到：父级已有错误，detached 仍能读取 demo-trace，没有继承截止时间，Done 为 nil；补充任务取得相同关联值。这是文档语义下的预期，不是本文的运行日志。

示例故意同步调用 work，避免把生命周期管理藏在一个 goroutine 里。若改成异步，拥有任务的 worker 应负责创建或接收任务 Context、调用 cancel、收集结果；不要在启动函数返回时立刻 defer cancel，导致刚交出去的异步工作马上取消。

移除取消并不等于任务有人管理

第一项代价是值引用。WithoutCancel 仍指向父 Context，不会枚举键并复制数据；如果某个 Value 是可变 map 或指针，派生对象拿到的也不会自动变成只读快照。不要借此延长请求体、连接或其他短生命周期对象的使用时间。要隔离数据，显式提取必要标识并建立自己的输入对象。

第二项代价是停止责任。任务独立于父级取消后，谁在服务关闭时停止它、谁限制同时运行数量、谁处理错误，都需要在业务层明确。WithTimeout 发送取消信号，并不能强制终止不配合的函数；阻塞依赖也要接收 Context 或有其他中止机制。

第三项代价是可靠性。Context 不是持久化任务记录，也不会在进程退出后恢复工作。如果补充动作必须完成，应另行设计持久化与重试，而不是把解除父级取消当作交付保证。这里不展开任务系统实现，重点仍是这个 API 的值与期限边界。

接入后应该观察哪些信号

在项目中接入前，先列出父级取消、任务自身超时、任务提前成功、缺少关联值和服务关闭等情况。逐项确认停止责任与错误归属，尤其别把父级取消误计为新任务自身超时。本文没有进行这些运行检查，也不声称已经减少超时或提升吞吐。

如果需要查看解除关联后的属性，应查看 valuesOnly 或 detached；如果查看的是经过 WithTimeout 包装的 taskCtx，它当然已经有了新的 deadline 和 Done。把这两层混在一起，是排查时很常见的概念错误。

WithValue 能不能去掉父级 deadline？

不能。WithValue 只增加值，仍沿用父级生命周期。这里需要的是 WithoutCancel 与独立预算的组合。

能否保留父级取消，只去掉 deadline？

WithoutCancel 不能满足这个精确需求，因为它同时移除父级取消传播。若取消与期限需要不同政策，应先明确独立的取消来源，而不是宣称该函数只删除截止时间。

应该把所有配置都放进 Context 吗？

不应该。Context 的值用于跨 API 边界的请求关联数据；普通业务参数仍应显式传递，示例里的 trace 也不替代权限检查或任务参数。

参考文档：https://pkg.go.dev/context#WithoutCancel、https://pkg.go.dev/context#WithTimeout、https://go.dev/doc/go1.21。