Go WithoutCancel 继承值但为何没有 Done

Go context.WithoutCancel 会保留对父级值的查询，却刻意不传播父级的取消与 deadline。返回上下文的 Done() 是 nil，Err() 为 nil，Deadline() 的布尔值为 false，context.Cause 也返回 nil。因此它不是“延迟取消”，而是把值查询与父级生命周期分开。

假设一个请求结束后还要处理一段短小的收尾工作，我会先问：需要保留的是追踪标识，还是整个请求持有的对象？对我而言，这比直接把 Context 交给后台更重要。这只是条件性的设计判断，并非一次真实线上经历。该函数从 Go 1.21 起提供，官方文档：https://pkg.go.dev/context#WithoutCancel。

先明确后台任务究竟需要保留什么

WithoutCancel 适合已经明确允许脱离父级取消、又需要沿用值查询的工作。追踪标识是较容易理解的例子：它表示工作来源，不直接决定任务还能执行多久。原请求取消以后，独立工作可以有自己的短预算，而不必丢掉来源信息。

我不会因为一个后台调用被父级取消，就无条件给所有调用套 WithoutCancel。父级取消可能正是业务要求；如果任务不应继续，它隔离的信号反而是你需要的约束。长时间任务还需要任务接管与持久化等设计，WithoutCancel 本身不启动 goroutine、不保存任务，也不保证进程退出后任务继续。

值保留不等于请求生命周期保留

返回上下文仍通过父级查询 Value，但它并不把值做快照或深拷贝。若 Value 中存放 map、指针或可变对象，得到的对象仍需要自己的所有权和并发保护。Context 的方法可并发使用，不等于放进去的对象自动可以并发修改。

隔离取消也不能让一个已关闭的事务、请求体或其他资源继续有效。后台代码若拿到这些值，资源是否可用仍由资源自身的生命周期决定。对于只需要少量标识的任务，我更倾向于明确取出必要字段并建立独立输入；这减少了无意保留父上下文对象链和过多数据的机会。

Done 为 nil 时等待方式会改变

nil 通道与已关闭通道不是一回事。直接执行 时，如果 ctx 是 WithoutCancel 的返回值，就会一直阻塞，除非外部另有机制终止整个程序。select 中读取 nil 通道的分支则不会成为可选分支。

所以 select 如果还包含任务结果、计时器或 default，可以由其他分支继续；只有一个 nil Done 接收分支的 select 仍会阻塞。不能把“Err 是 nil”解释成后台任务一定成功，它只说明这个上下文不呈现取消错误，不代表业务结果。

如果父级早已取消，再调用 WithoutCancel，返回值仍采用同样的属性；它不会复活父级，也不会改变父级 Err。需要了解原取消原因时，应从原父上下文观察，而不是从脱离后的上下文读取 Cause。

给脱离父级的工作重新建立结束条件

完整示例只展示属性和主动取消，不实际执行后台业务，也不等待两秒自然超时。保存为 main.go 后可由读者自行尝试；本文没有运行或输出实际日志。

package main

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

// 使用私有键类型，避免与其他包的元数据键碰撞。
type traceKey struct{}

func main() {
    values := context.WithValue(context.Background(), traceKey{}, "trace-demo")
    parent, cancelParent := context.WithTimeout(values, time.Hour)
    defer cancelParent()
    detached := context.WithoutCancel(parent)

    // 主动取消父级；脱离取消的上下文仍委托父级查询值。
    cancelParent()
    _, hasParentDeadline := parent.Deadline()
    _, hasDetachedDeadline := detached.Deadline()
    fmt.Println("父级有 deadline：", hasParentDeadline)
    fmt.Println("父级已取消：", errors.Is(parent.Err(), context.Canceled))
    fmt.Println("保留追踪值：", detached.Value(traceKey{}))
    fmt.Println("脱离后的 Done 为 nil：", detached.Done() == nil)
    fmt.Println("脱离后有 deadline：", hasDetachedDeadline)
    fmt.Println("脱离后 Err：", detached.Err())
    fmt.Println("脱离后 Cause：", context.Cause(detached))

    // 非阻塞观察不会卡在 nil 通道；不要只写单独接收 Done。
    select {
    case 

根据代码规则，父级仍有 deadline 且被主动取消；detached 保留 trace-demo，Done 为 nil，没有 deadline，Err 与 Cause 都为 nil。新 job 则具有自己的 deadline 与非 nil Done，stopJob 关闭它的取消通道。这些是代码和官方语义推导，不是本轮实测结果。

重要的是顺序：先 WithoutCancel，再 WithTimeout，才是在保留值查询的独立上下文上设置新的预算。若先 WithTimeout 再 WithoutCancel，新增加的预算也会被返回上下文隔离。实际工作结束后仍应调用 cancel 释放相关资源，不能只依赖超时到点。

取消是协作信号，不强制中断不观察它的任意 Go 代码。调用方和下游还应遵守 job 的结束条件；独立预算只是可供观察的约束，不是无限后台任务的保险。

记录任务来源但不延长资源权限

我会在任务记录中区分原请求来源与工作自己的结束原因。原请求取消后任务仍继续，是设计选择，不应伪装成原请求一直有效。记录必要的追踪标识即可，不把整个 Context 或其中所有值展开进日志。

取消隔离不是权限隔离或权限延期。父级值即使携带某个用户标识，也不意味着后台操作永远获得授权；权限检查和资源有效性仍由业务决定。这里不建议存放密钥或大量可变资源，更不建议用 WithoutCancel 绕过明确要求终止的操作。

对于短小、允许独立完成、下游支持结束信号的收尾工作，这种组合容易理解。对必须随请求取消的工作，或尚未明确资源归属的任务，我会保留父级取消；不要只因后台报错就屏蔽它。

用一组属性对照理解适用边界

我的判断清单是：任务是否真的允许脱离请求；保留的值是否必要且可安全使用；是否另有独立预算与取消持有者；下游是否观察结束信号；是否记录了业务结果而非只查看 Err。任何一项不明确，都不应把 nil Done 当作万能后台模式。

Done 为 nil 会导致 select 立刻执行吗？

不会。nil 通道分支被禁用；有 default 时可能走 default，其他分支是否就绪决定剩余行为。

WithoutCancel 可以代替 Background 吗？

它与 Background 的区别在值查询：WithoutCancel 仍关联父级，Background 不带这条父级值链。只需少量显式字段时，独立任务输入通常更清楚。

传入 nil 会得到空上下文吗？

不会，传入 nil 父级会 panic。应传入有效 Context，不把 nil 当成 Background。

参考资料：https://pkg.go.dev/context#WithoutCancel；https://pkg.go.dev/context#WithTimeout；实现 https://go.dev/src/context/context.go。保留值是便利，隔离结束信号则意味着新的生命周期责任，两者需要一起决定。