Go context.WithDeadline 提前取消后 Err 返回什么

很多 Go 排障日志把“提前取消”和“超时”都写成了 context error，真正查看 ctx.Err() 才发现原因不同。结论很明确：如果 context.WithDeadline 返回的 cancel 在截止时间到来前被调用，ctx.Err() 返回 context.Canceled；只有 deadline 先到期时，才返回 context.DeadlineExceeded。

WithDeadline 提前取消时，Err 返回 Canceled 还是 DeadlineExceeded

WithDeadline 创建的是一个派生 Context。它的 Done 会在三个事件中最先发生的那个时刻关闭：返回的 cancel 被调用、父 Context 被取消，或有效 deadline 到期。因此“提前取消”要先问清楚是谁发出的取消信号。

怎样稳定复现提前 cancel 的返回值

测试时不要创建 Context 后立刻读取 Err()，因为此时 Done 可能还没有关闭。先在 deadline 前调用 cancel，再等取消信号，最后判断错误：

package main

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

func main() {
	// 把 deadline 放到未来，确保本次取消由 cancel 主动触发。
	ctx, cancel := context.WithDeadline(context.Background(), time.Now().Add(time.Second))
	defer cancel() // 释放仍可能存在的计时器资源。

	cancel() // 在 deadline 到来前结束派生 Context。
	

这里的关键不是调用顺序本身，而是先确认 Done 已关闭。Err 的契约是在 Done 关闭后返回非空错误；同一个 Context 后续读取会得到相同原因。

deadline 到期、父级取消和更早 deadline 怎么判断

如果去掉主动 cancel，等到截止时间真正到达，结果才是 context.DeadlineExceeded。父 Context 也会参与竞争：父级先取消时，子级通常只能观察到 context.Canceled。另外，父级如果已有更早的 deadline，子级传入更晚时间也不会把它延后。

func classify(ctx context.Context) string {
	select {
	case 

这个分类只回答标准 Err() 的原因。如果需要知道主动取消时携带的业务错误，可进一步使用带 cause 的 API，但那不改变 ctx.Err() 对取消类别的基本判断。

把判断放进请求或任务的收尾逻辑

实际服务里建议把 ctx.Err() 作为取消后的分类入口，而不是只匹配错误字符串。对下游函数继续传递原始 ctx，不要在深层重新换成 context.Background()，否则上游的 deadline 和取消信号会被截断。

如果日志需要区分“用户主动断开”和“服务端超时”，还应结合请求生命周期或任务状态记录触发者；单凭 DeadlineExceeded 只能说明有效 deadline 先到期，不能说明具体是哪一个业务组件变慢。

相关问题

调用 cancel 后为什么偶尔先读到 nil？

因为取消传播是并发过程。先接收 ，再读取 ctx.Err()，不要用固定的 Sleep 代替同步。

WithDeadline 的 cancel 需要 defer 吗？

需要。即使 deadline 很快到期，defer cancel() 仍能在函数返回时释放相关资源，并覆盖提前返回的路径。

可以直接比较错误字符串吗？

不建议。优先使用 errors.Is(err, context.Canceled) 和 errors.Is(err, context.DeadlineExceeded)，这样不会依赖展示文本。