Go context.WithoutCancel 为什么 Deadline 返回不存在

线上请求结束后，有时还要写一条审计日志、刷新一次缓存。把 req.Context() 直接交给后台任务，请求一取消，任务也会立刻收到取消信号；改用 context.WithoutCancel 后，却发现 Deadline() 的 ok 变成了 false。这不是截止时间读取失败，而是该 API 的明确设计。

WithoutCancel 会保留对父 Context 值的查找，但切断父级取消、截止时间和错误传播。因此返回的 Context 没有 Deadline，Done() 为 nil，Err() 与 context.Cause() 都返回 nil。

一、根因是取消链被主动切断

Go 1.21 加入的 WithoutCancel(parent) 返回一个仍指向父 Context 的派生对象，但父级取消不会再传下来。官方文档同时规定：这个对象不返回 Deadline 或 Err，Done channel 为 nil，Cause 也为 nil。也就是说，它不是“复制父 Context 后忽略一次 cancel”，而是重新定义了取消相关接口。

detached := context.WithoutCancel(req.Context())

deadline, ok := detached.Deadline()
_ = deadline
fmt.Println(ok) // false：脱离后的 Context 没有父级截止时间

因此，不能把原请求的 Deadline 当成脱离后任务的超时依据。即使父请求原本只剩 200 毫秒，detached 也不会继承这 200 毫秒。

二、脱离请求后重新设置独立超时

安全组合通常是先切断请求生命周期，再为后台工作建立新的期限。这样客户端断开不会中止审计任务，但任务也不会无限运行：

func enqueueAudit(req *http.Request) {
	detached := context.WithoutCancel(req.Context())

	go func() {
		// 后台任务拥有独立的 5 秒期限
		ctx, cancel := context.WithTimeout(detached, 5*time.Second)
		defer cancel()

		if err := writeAudit(ctx); err != nil {
			log.Printf("write audit: %v", err)
		}
	}()
}

新的 ctx 有自己的 Deadline 和 Done channel。五秒到期后，ctx.Err() 会变成 context.DeadlineExceeded；这与原请求何时结束无关。defer cancel() 仍然必要，它能在任务提前完成时及时释放计时器资源。

三、值会保留，但不要把它当任务参数仓库

WithoutCancel 仍可读取父链中的 request ID、trace ID 等请求级值，这是它比 context.Background() 更适合短时收尾任务的原因。不过，Context Value 只适合跨 API 边界传递请求级数据，不应塞入数据库连接、可变配置或大量业务参数。

另一个常见误区是继续等待 detached.Done()。由于该 channel 为 nil，放进 select 后这个分支永远不会就绪。需要退出信号时，应使用上面新建的超时 Context，或接入服务自己的关停 Context。

四、适用边界与排查清单

• 适合短时审计、埋点、缓存刷新等“请求结束后仍需完成”的工作。
• 不适合无人管理的长任务；进程退出、服务关停和失败重试应由任务系统或生命周期管理器负责。
• 看到 Deadline ok=false 时，先确认当前 Context 是否来自 WithoutCancel，不要误判为上游漏传时间。
• 如果任务必须跟随客户端取消，就不要使用 WithoutCancel。

相关问题

WithoutCancel 之后还能读取 request ID 吗？

可以，只要 request ID 是通过父 Context 的 Value 链保存的；但父级取消、截止时间和取消原因不会保留。

可以直接把 WithoutCancel 用于长期 goroutine 吗？

不建议。它只解决“不要跟随父请求取消”，不会提供任务超时、进程关停或重试机制；至少应再加独立超时，并让长期任务进入受控的任务系统。