Go context.WithoutCancel 继承值但不继承取消信号吗

我第一次把后台审计任务从 HTTP 请求里“摘出来”时，最容易误判的就是 context.WithoutCancel：它看起来像复制了父上下文，但复制的不是完整生命周期。准确答案是：它仍能读取父上下文里的 Value，却不会跟随父上下文取消；同时它没有 deadline，Done 为 nil，Err 和 Cause 也不会给出父上下文的取消结果。

WithoutCancel 到底保留了什么

可以把它理解成“保留上下文值的观察入口，但不再订阅父级生命周期”。下面的例子把四个可观察点放在一起，重点不是打印结果，而是看清 API 之间的职责差异：

package main

import (
    "context"
    "fmt"
)

type requestKey struct{}

func main() {
    parent, cancel := context.WithCancel(context.Background())
    defer cancel() // 释放父上下文；这里只模拟请求结束

    parent = context.WithValue(parent, requestKey{}, "req-2026")
    detached := context.WithoutCancel(parent)

    fmt.Println(detached.Value(requestKey{})) // 仍可沿父链取到值
    fmt.Println(detached.Done() == nil)        // true：没有可等待的取消通道
    fmt.Println(detached.Err() == nil)         // true：不读取父级取消状态
    fmt.Println(context.Cause(detached) == nil) // true：没有取消原因
}

Value 仍由父链提供，所以请求编号、租户标识这类 request-scoped 数据可以被异步函数读取。但这不表示所有父属性都会被复制。尤其是 Done 为 nil：把它放进一个只等待 的 goroutine，任务可能永远没有退出信号。

父取消被隔离，但子任务仍然可以取消

“不继承取消”不等于“永远不能取消”。我更愿意在异步收尾函数里再套一层 WithTimeout 或 WithCancel，让任务由自己的调用方负责结束。这样用户请求结束不会直接砍掉审计写入，但服务也不会因为某个异常 goroutine 一直挂着。

func enqueueAudit(parent context.Context, audit AuditEvent) {
    // 只把需要的请求值带入后台，不让请求取消直接终止收尾任务。
    detached := context.WithoutCancel(parent)
    taskCtx, cancel := context.WithTimeout(detached, 2*time.Second)
    defer cancel() // 无论成功、超时还是出错，都释放子上下文资源

    if err := auditStore.Write(taskCtx, audit); err != nil {
        // 这里记录失败即可，不能再等待一个永远不会关闭的 Done。
        log.Printf("audit write failed: %v", err)
    }
}

如果 auditStore.Write 还需要 request ID，可以直接从 taskCtx.Value 读取；如果它需要“请求是否已结束”的信号，就不应该使用这个脱钩上下文，而应继续传入原始 parent。选择 API 前先问清楚：这个工作是请求的一部分，还是请求结束后仍应尝试完成的收尾动作。

需要 deadline 时要重新建立边界

这是我排查超时失效时最先看的地方。WithoutCancel 会让返回值没有 deadline，所以不能写出“脱钩后自然继承原超时”的假设。如果业务上要保留或重设时间上限，就显式创建一个新的 deadline：

func detachedWithLimit(parent context.Context) (context.Context, context.CancelFunc) {
    // 先读取原 deadline；WithoutCancel 之后再读取就拿不到它了。
    deadline, hasDeadline := parent.Deadline()
    detached := context.WithoutCancel(parent)

    if hasDeadline {
        // 重新建立原来的时间边界，但取消责任转移给新上下文。
        return context.WithDeadline(detached, deadline)
    }

    // 没有原 deadline 时给后台任务一个明确的兜底上限。
    return context.WithTimeout(detached, 2*time.Second)
}

这里有一个实际取舍：如果父请求只剩几十毫秒，重新使用原 deadline 得到的子上下文也会很快结束；如果真正目标是“请求取消后仍完成收尾”，通常应采用固定的短超时，而不是照搬已经快到期的父 deadline。

用检查清单确认这次脱钩是有意的

• 需要请求取消立即停止的工作，继续传原始 parent，不要为了读取 Value 而使用 WithoutCancel。
• 需要请求结束后做有限收尾的工作，使用 WithoutCancel 后立刻加自己的 WithTimeout 或取消函数。
• 依赖 deadline 的代码要先在父上下文上读取期限；脱钩之后再调用 Deadline 得不到原值。
• 不要对 做无期限等待；脱钩上下文的 Done 是 nil，必须让外层超时或显式取消负责退出。
• 只把必要的 request-scoped value 放进 context，不要把数据库句柄、可变业务对象或大块数据塞进 Value。

相关问题

WithoutCancel 会复制父上下文里的 deadline 吗？

不会。返回上下文没有 deadline；如果需要时间限制，必须显式调用 WithTimeout 或 WithDeadline。

WithoutCancel 的 Value 会不会丢失？

不会。它仍然指向父上下文的值查找链，但值可见不代表取消信号和时间限制也可见。

能不能用 Background 替代 WithoutCancel？

通常不能。Background 没有父链，连 request-scoped value 也没有；需要保留值、切断取消时才考虑 WithoutCancel，并为任务补上自己的退出边界。

我现在把这个 API 当作一个明确的生命周期转换点：进入 WithoutCancel 之后，代码必须重新回答“谁负责取消、多久必须结束、哪些值确实需要传递”。答案写清楚，异步收尾才是可控的；只把它当成“不会取消的 context”使用，往往会把 deadline 和 goroutine 退出一起漏掉。