Go context.WithDeadline 为什么比预期更早结束：父级截止时间与请求预算核对

接口明明给下游留了 800 毫秒，日志却显示请求在 300 毫秒左右就结束，最常见的原因不是 WithDeadline 自己算错了，而是它继承了一个更早的父级截止时间。Go 的规则很明确：子上下文只能保持更早的 deadline，不能把父级已经剩下的时间“续长”。

你手动通过`context.WithDeadline`设置的晚于父级截止点的时间不会生效，最终上下文的实际到期时间是父级上下文自带的截止时间和你传入的新截止时间两者中更早的那一个，不会出现子上下文的存活时长超过父上下文的情况。

先复现：800 毫秒预算为什么只跑了 300 毫秒

先把时间点写出来，比盯着一条“context deadline exceeded”更容易定位。下面的代码模拟一个总预算 300 毫秒的请求，在内部又尝试创建 800 毫秒的子预算：

parent, cancel := context.WithTimeout(context.Background(), 300*time.Millisecond)
defer cancel()
parentDeadline, _ := parent.Deadline()

child, cancel := context.WithDeadline(parent, time.Now().Add(800*time.Millisecond))
defer cancel()
childDeadline, _ := child.Deadline()

fmt.Println("parent left:", time.Until(parentDeadline))
fmt.Println("child left:", time.Until(childDeadline))

这里的关键不是子级传入了 800 毫秒，而是创建它的那一刻父级已经只剩约 300 毫秒。子级会沿用更早的截止时间，因此最终等待时间接近 300 毫秒。

Go 的 deadline 继承规则：比较时间点，不比较 duration

WithDeadline(parent, d) 实际上会比较父级和候选时间点 d。如果父级 deadline 更早，子级不会创建一个更晚的独立截止点；如果父级没有 deadline，子级才会采用传入的时间点。

这也是为什么“给每个下游都固定加 1 秒”很容易失真。上游请求已经消耗了 900 毫秒时，下游再加 1 秒并不代表它真的还有 1 秒。合理的做法是把剩余预算作为日志和决策依据：

func callDownstream(ctx context.Context) error {
    if deadline, ok := ctx.Deadline(); ok {
        left := time.Until(deadline)
        if left 

这段判断只是提前放弃不值得启动的工作，不是替代真正的取消处理。doWork 仍然应该把 ctx 传下去，并在自己的循环或阻塞点响应取消。

请求链路里，哪个超时先到就看哪个

在 HTTP 调用中，context deadline 不是唯一的时钟。http.Client.Timeout 会限制整个请求生命周期，Transport 还可能配置连接建立、响应头和空闲连接等阶段的超时。它们不是互相延长，而是共同提供更早的退出边界。

服务端返回错误时，可以先判断 errors.Is(ctx.Err(), context.DeadlineExceeded)，再结合请求阶段日志做归因。若 ctx.Err() 仍为空，超时可能来自客户端或传输配置，不能直接归结为调用方 deadline。

测试里怎么确认：记录绝对时间和剩余预算

测试不要用“睡 300 毫秒后应该超时”这种脆弱断言。更稳的核对方式是检查 deadline 是否没有晚于父级，并允许调度误差：

func TestChildDeadlineCannotExtendParent(t *testing.T) {
    parent, cancel := context.WithTimeout(context.Background(), 80*time.Millisecond)
    defer cancel()

    child, childCancel := context.WithDeadline(parent, time.Now().Add(time.Second))
    defer childCancel()

    parentAt, parentOK := parent.Deadline()
    childAt, childOK := child.Deadline()
    if !parentOK || !childOK {
        t.Fatal("expected both contexts to have a deadline")
    }
    if childAt.After(parentAt) {
        t.Fatalf("child deadline %v is later than parent %v", childAt, parentAt)
    }
}

若要测试业务函数确实收到了取消信号，使用一个带 select 的可控工作单元，检查它返回 context.DeadlineExceeded 或保留的业务错误。不要把真实网络、机器负载和固定睡眠混在同一个单元测试里。

几个容易把时间预算算错的地方

只给下游创建新的 Background 上下文

这样会切断上游取消，调用方已经断开时下游仍可能继续运行。除非这是明确的后台收尾任务，否则应从传入的 ctx 派生。

把业务 deadline 和连接超时写成同一个配置

业务预算回答“这次请求还能等多久”，连接超时回答“某个网络阶段最多等多久”。分开命名、分开记录，排查时才看得出是哪一层提前结束。

收到取消后还继续写结果

并发任务可能在取消之后才完成一次计算。返回前再检查一次 ctx.Err()，并让调用方决定是否丢弃结果，能避免过期数据覆盖新结果。

把排查结论落到一条可执行规则

看到“比预期更早结束”时，按这个顺序核对：先打印父子 deadline 的绝对时间，再计算两者相对当前时间的剩余值；随后检查 ctx.Err()，最后对照 http.Client 和传输阶段超时。只要其中任一层更早，整个调用链就会先在那里停止。

如果确实需要给后台收尾留时间，应显式设计独立的生命周期、上限和资源回收策略，而不是试图用更晚的 WithDeadline 覆盖一个已经结束的父请求。

相关问题

子 context 能把父 context 的超时时间延长吗？

不能。父级已有更早 deadline 时，子级会受它约束。

context 超时后 goroutine 会自动消失吗？

不会。goroutine 必须在阻塞点检查取消信号并主动返回。

为什么错误不是 context deadline exceeded？

可能是客户端、连接或响应读取阶段的独立超时，先看 ctx.Err() 和阶段日志再分类。

应该用 WithTimeout 还是 WithDeadline？

相对时长用 WithTimeout 更直观；多个服务共享一个绝对截止点时，用 WithDeadline 更容易保持同一时间基准。

小结

WithDeadline 提前结束通常是继承规则在正常工作：子级不能突破父级已经确定的截止时间。把绝对 deadline、剩余预算、ctx.Err() 和 HTTP 各层超时放在同一张排查表里，问题就会从“偶发超时”变成可以复现和验证的时间边界。