Go context.WithoutCancel 为什么会丢失 Done：保留 Value 与切断取消的边界

线上请求被取消后，日志异步写入、审计落库或指标上报有时还想继续拿到 request id。把原来的 ctx 直接传下去会让收尾任务一起退出；换成 context.WithoutCancel(ctx) 后，Value 还在，但取消信号已经被切断，这正是它最容易被误解的地方。

WithoutCancel 不是“延长父 Context 的超时”，而是返回一个没有 Done、没有 Err、没有 Deadline 的派生 Context。它只适合明确不应跟随请求取消、且自身仍有退出边界的收尾工作。

先看最小写法：Value 还在，取消链断了

下面的例子可以直接用 Go 1.21 或更高版本运行。父 Context 被取消后，派生 Context 仍能读取 request id，但它的状态接口表现为空。

package main

import (
    "context"
    "fmt"
)

type requestIDKey struct{}

func main() {
    parent, cancel := context.WithCancel(
        context.WithValue(context.Background(), requestIDKey{}, "req-2048"),
    )
    detached := context.WithoutCancel(parent)
    cancel()

    fmt.Println(detached.Value(requestIDKey{})) // req-2048
    fmt.Println(detached.Done() == nil)          // true
    fmt.Println(detached.Err() == nil)           // true
    fmt.Println(detached.Deadline())             // false
}

这里的 true 不是异常。官方文档明确规定，WithoutCancel 返回的 Context 没有 Deadline 和 Err，Done 也是 nil，调用 Cause 会得到 nil。它表达的是“还带着这次请求的上下文数据”，而不是“仍然受这次请求管理”。

从旧代码迁移时，先区分四个状态接口

很多问题来自把“保留 Value”理解成“保留所有父 Context 行为”。实际迁移时可以按下面的边界检查：

因此，原来依靠 退出的循环，不能只把参数替换成 WithoutCancel(ctx)。这个替换会把退出条件一起拿掉。

真正需要后台收尾时，再加一层独立超时

更稳妥的用法是先脱离请求取消，再为收尾动作设置短而明确的截止时间。这样日志、审计或补偿写入不会因为客户端断开立刻失败，也不会无限运行。

func finishAudit(parent context.Context, save func(context.Context, string) error) error {
    detached := context.WithoutCancel(parent)
    ctx, cancel := context.WithTimeout(detached, 2*time.Second)
    defer cancel()

    requestID, _ := detached.Value(requestIDKey{}).(string)
    return save(ctx, requestID)
}

注意这里的超时属于收尾任务自己，不是父请求的 deadline 延长。若审计写入还需要用户身份、权限或事务状态，先确认这些数据在请求结束后仍然有效；不能因为 Context 还能读到 Value，就推断相关资源还可安全使用。

三类代码不适合直接换成 WithoutCancel

• 核心业务计算：用户已经取消或上游失败时，继续执行只会浪费 CPU 和下游配额。
• 外部写操作：支付、库存、状态变更等动作要按业务幂等和补偿规则处理，不能用脱离取消来掩盖不完整的事务设计。
• 无限等待循环：因为 Done 为 nil，依赖父 Context 退出的循环会失去停止点，必须显式提供独立 Context、计数上限或任务队列生命周期。

这里别急着把所有“请求结束后还要做事”的代码都改成后台 goroutine。先问一句：这个动作是用户请求的一部分，还是可重试的异步收尾？前者跟随取消更安全，后者才值得考虑脱离。

用一个小检查确认迁移没有丢掉退出条件

测试时不要只断言 Value 能读到。至少覆盖父 Context 取消、独立 deadline 和任务超时三件事：

func TestDetachedAuditHasItsOwnDeadline(t *testing.T) {
    parent, cancel := context.WithCancel(context.Background())
    detached := context.WithoutCancel(parent)
    cancel()

    if detached.Done() != nil || detached.Err() != nil {
        t.Fatal("detached context must not inherit cancellation")
    }
    ctx, stop := context.WithTimeout(detached, time.Millisecond)
    defer stop()
    

如果测试卡在 ，通常不是调度问题，而是把 nil channel 当成普通取消通道使用了。把等待对象换成带独立 deadline 的 ctx，再检查任务是否能在超时后释放资源。

相关问题

WithoutCancel 是不是等同于 Background？

不是。两者都不会因为父请求取消而结束，但 WithoutCancel 仍能通过 Value 访问父链中的请求范围数据；Background 没有这些值。

为什么 WithoutCancel 的 Done 是 nil？

这是它切断取消传播的明确语义。对 nil channel 的接收会一直阻塞，所以必须给后台工作另建可结束的 Context。

能不能用它绕过请求超时？

可以让某个明确的收尾动作不跟随请求取消，但不应把它当成通用的超时绕过工具。脱离后要设置自己的 deadline，并重新评估写操作的幂等性。

迁移清单

• 确认项目的最低 Go 版本不低于 1.21。
• 确认只需要保留哪些 Value，并使用包级私有 key 类型避免冲突。
• 确认后台任务不再读取 detached Context 的 Done、Err 或 Deadline 作为退出条件。
• 为任务添加独立超时、取消函数和可验证的资源释放路径。

WithoutCancel 解决的是“请求取消后仍需带着少量上下文信息完成收尾”的问题。它把取消权交还给调用者，也把超时、重试和幂等责任一起交给了调用者。