Go context.WithoutCancel 为什么拿不到父级截止时间

很多人第一次使用 context.WithoutCancel，都会把它理解成“取消不跟随父级，但其他状态照常继承”。这句话只对了一半：它确实仍指向父 context，可以继续读取父级通过 WithValue 放入的值；但在生命周期语义上，它主动切断了父级的取消和截止时间。因此调用 Deadline() 得到的不是父级时间，而是 ok=false。

WithoutCancel 的设计目标是脱离父级取消，不是复制父级的超时。要让后台任务既不被请求取消，又不会无限等待，应先 WithoutCancel，再用 WithTimeout 或 WithDeadline 建立新的边界。

为什么 WithoutCancel 看不到父级 Deadline

Go 的 Context 同时承载值、截止时间和取消信号。普通的 WithTimeout 会把父级作为生命周期上游：父级一旦结束，子级也会结束。WithoutCancel 恰好改变了这条规则，它返回一个不会因 parent 被取消而取消的派生 context。

所以“派生”不等于“复制所有字段”。官方文档对它的定义很明确：返回 context 没有 Deadline 或 Err，Done channel 为 nil，调用 context.Cause 也得到 nil。父级即使只剩几十毫秒，也不会自动变成新 context 的截止时间。

用四个 Context 方法确认到底断开了什么

不要只检查 Err()。下面的示例同时观察四个接口：父级有 100 毫秒截止时间，派生 context 则使用 WithoutCancel。代码中的注释说明了每个检查点的用途。

package main

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

func main() {
    // 父级设置短截止时间，用来观察派生边界。
    parent, cancel := context.WithTimeout(context.Background(), 100*time.Millisecond)
    defer cancel() // 释放父级定时器相关资源。

    detached := context.WithoutCancel(parent)
    deadline, ok := detached.Deadline()

    // 这些结果说明 detached 没有继承取消生命周期。
    fmt.Println(ok, deadline.IsZero())
    fmt.Println(detached.Done() == nil, detached.Err() == nil)
    fmt.Println(context.Cause(detached) == nil)
}

示意结果应体现三点：ok 为 false，返回时间是零值；Done 为 nil，Err 仍为 nil；Cause 同样为 nil。即使等待父级超时，detached 也不会因此关闭一个 Done channel。

脱离请求取消后，后台任务仍要自己设置超时

典型场景是 HTTP 请求返回后，还要把审计事件、缓存刷新或临时文件清理交给后台执行。直接把请求 context 传下去，客户端断开就会让收尾工作中止；直接使用 WithoutCancel，又会失去任何超时。更稳妥的做法是把两种意图拆开表达：

func cleanupInBackground(requestCtx context.Context) {
    // 只保留请求范围内的值，不再跟随请求取消。
    detached := context.WithoutCancel(requestCtx)

    // 为后台清理重新设置上限，避免无截止时间地等待。
    cleanupCtx, cancel := context.WithTimeout(detached, 2*time.Second)
    defer cancel() // 任务提前完成时及时释放定时器。

    if err := deleteTempFiles(cleanupCtx); err != nil {
        // 超时、取消和业务错误要分开记录，便于后续排查。
        fmt.Println("cleanup failed:", err)
    }
}

这里的新截止时间来自 WithTimeout，不是来自原请求。cleanupCtx 能在两秒后结束，后台任务也能响应自己的 Done()；但它不会重新接收 requestCtx 的取消传播。

什么时候保留父级，什么时候重新建边界

判断时先问任务是否仍属于原请求。如果数据库查询、下游 HTTP 调用属于请求结果的一部分，应继续使用原 context 或用 WithTimeout 缩短上限；如果只是请求结束后的收尾工作，才考虑 WithoutCancel。

• 需要跟随客户端中止：传递原 ctx，不要用 WithoutCancel 掩盖取消。
• 需要脱离取消但有明确时限：context.WithTimeout(context.WithoutCancel(ctx), limit)。
• 需要保留值但不应长期持有请求对象：只把确实需要的 request-scoped 值显式提取后传给后台任务，避免误把整个 context 当作业务数据容器。

还要注意版本边界：WithoutCancel 是 Go 1.21.0 加入的标准库 API。旧版本项目不能只改源码，还要确认 go.mod 的工具链和部署环境满足这一最低要求。

常见问题

WithoutCancel 会不会连父级 Value 也丢掉？

不会。它仍指向 parent，值查找可以沿父链路继续进行；被切断的是取消、截止时间和取消原因。

为什么 select 监听 detached.Done() 没有超时分支？

因为 Done 返回 nil channel，nil channel 永远不会准备好。需要先用 WithTimeout 或 WithDeadline 创建新的可取消 context。

WithCancel 和 WithoutCancel 有什么区别？

WithCancel 创建一个仍受父级取消影响的可取消子 context，并额外提供自己的 cancel；WithoutCancel 则专门移除父级取消和截止传播，使用后应自行补齐生命周期。