WithoutCancel 创建的任务为何仍有 Deadline 问题

我在排查一个“请求已经返回，后台任务却还是超时”的 Go 服务时，第一反应是看 context.WithoutCancel 是否真的脱离了父 Context。结论很明确：WithoutCancel 返回的 Context 本身没有 Deadline，Done() 为 nil，Err() 和 context.Cause 也都为空；它仍然看到 Deadline，说明 Deadline 是后来重新派生出来的，或者代码根本没有把这个脱离后的 Context 传到底层。

真正稳妥的做法是把“脱离请求取消”和“任务仍有时间上限”拆成两步：先用 WithoutCancel 保留需要的上下文值，再用 WithTimeout 建立任务自己的 Deadline。

先确认 WithoutCancel 本身没有 Deadline

先不要从超时日志倒推结论，直接检查同一个 Context 的四个维度。下面的代码只做语义探针，不需要执行真实业务。

package main

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

func inspect(label string, ctx context.Context) {
    deadline, ok := ctx.Deadline()
    fmt.Printf("%s deadline=%v hasDeadline=%v doneIsNil=%v err=%v cause=%v\n",
        label, deadline, ok, ctx.Done() == nil, ctx.Err(), context.Cause(ctx))
}

func main() {
    // 父 Context 代表请求，故意带一个较短的时间边界。
    requestCtx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel() // 及时释放父 Context 的定时器资源。

    // WithoutCancel 保留 Value，但不接受父级取消、Deadline 和 Cause。
    detached := context.WithoutCancel(requestCtx)
    inspect("request", requestCtx)
    inspect("detached", detached)
}

这里的 detached 应该显示 hasDeadline=false、doneIsNil=true。这不是“父 Context 的 2 秒变成了隐藏超时”，而是它的 Deadline 语义已经被切断。需要注意的是，Value 仍然沿着父 Context 查找，所以链路标识、租户信息等值可以继续读取；这并不等于取消信号也会继续传递。

找出 Deadline 从哪里重新进入任务

最常见的误会是把下面两段代码当成同一件事。第一段的 detached 没有 Deadline；第二段却明确创建了一个新的 5 秒 Deadline，因此任务看到超时是正常结果。

// 先脱离请求取消，再给后台任务设置自己的上限。
detached := context.WithoutCancel(requestCtx)
taskCtx, cancelTask := context.WithTimeout(detached, 5*time.Second)
defer cancelTask() // 无论任务成功还是失败，都释放任务级定时器。

runTask(taskCtx)

另一类问题更隐蔽：入口接收了 taskCtx，但闭包里仍引用 requestCtx，或者某个方法从结构体字段取回旧 Context。排查时沿着“HTTP handler → goroutine → 服务方法 → 数据库/RPC 客户端”逐层查看，搜索 WithTimeout、WithDeadline、r.Context() 以及保存 Context 的字段。首次出现 ok=true 的边界，就是 Deadline 重新进入的位置。

用最小探针区分取消、Deadline 和 Value

只看 Err() 不够：父 Context 被取消时，原始 Context 的 Done 会关闭；脱离后的 Context 可能仍能读到同一个业务值，却不会表现出相同的取消状态。建议在任务入口和下游调用前各记录一次 Deadline 来源。

func runTask(ctx context.Context) error {
    deadline, hasDeadline := ctx.Deadline()
    fmt.Printf("task deadline=%v hasDeadline=%v\n", deadline, hasDeadline)

    select {
    case 

如果探针在 detached 上显示没有 Deadline，而进入数据库或 HTTP 客户端前变成了有 Deadline，就检查那一层是否重新调用了 WithTimeout。如果任务入口已经有 Deadline，则调用方传入的就不是预期的脱离 Context。

为后台任务建立独立且有限的 Deadline

脱离请求取消不代表可以无限运行。比如请求结束后还要写审计记录、刷新缓存或发送通知，可以保留追踪值，但把任务寿命限制在一个可接受的窗口内：

func startAudit(requestCtx context.Context, record Record) {
    // 只脱离请求取消，保留链路信息等必要 Value。
    detached := context.WithoutCancel(requestCtx)
    taskCtx, cancel := context.WithTimeout(detached, 5*time.Second)

    go func() {
        defer cancel() // 任务提前完成时，主动释放定时器。
        if err := saveAudit(taskCtx, record); err != nil {
            // 下游应继续使用 taskCtx，而不是闭包中的 requestCtx。
            log.Printf("save audit failed: %v", err)
        }
    }()
}

这里的边界很清楚：请求取消不会直接关闭 taskCtx.Done()，但 5 秒到期后任务仍会退出。若审计数据不允许丢失，应该把它送入有持久化能力的队列，而不是把 WithoutCancel 当成可靠投递机制。

复查资源回收和上下文传递

我最后会按一张小清单复查：所有 WithTimeout 或 WithDeadline 是否都有对应的 cancel；goroutine 是否有退出条件；下游函数是否只使用参数中的 Context；是否把请求 Context 存进了长期对象；日志是否能区分“父取消”“任务超时”和“业务错误”。

相关问题

WithoutCancel 会不会复制父 Context 的超时时间？

不会。它返回的 Context 没有 Deadline；只有随后派生出的 WithTimeout 或 WithDeadline 才会建立新的时间边界。

为什么 WithoutCancel 之后还能拿到 trace-id？

因为它仍通过父 Context 查找 Value。取消、Deadline、Err、Cause 和 Value 是不同的语义通道。

后台任务应该直接使用 context.Background 吗？

通常不应该。直接使用 Background 会丢失必要的请求值，也没有任务上限；更合适的组合是 WithoutCancel 加一个明确的任务级超时。