Go context deadline 派生更短 deadline 时如何选择有效值

在 Go 服务里，入口请求通常已经带着一个 context.Context。业务层调用数据库、HTTP 或消息服务时，又可能希望给这一次下游操作设置一个更短的 deadline。这里的有效规则很简单：子上下文只能比父上下文更早结束，不能把父级 deadline 向后延长。

为什么派生 deadline 只能更早，不能把父级时间向后延长

WithDeadline(parent, d) 的语义不是“强行把 deadline 改成 d”，而是把子上下文的截止时间限制为不晚于 d。如果父级已经在更早的时间到期，子级会沿用这个更早的边界。这样做是为了让下游调用服从上游请求的生命周期：父请求都结束了，子操作没有理由继续占用资源。

例如父级在 10 秒后到期，业务候选 deadline 是 3 秒，那么有效值是 3 秒；如果父级只剩 1 秒，候选值即使是 3 秒，有效值仍然只有 1 秒。父级没有 deadline 时，子级才会按照传入的候选时间建立自己的截止边界。

如何用代码选择下游调用的有效截止时间

通常不需要手写一套复杂的比较器，直接把业务候选时间交给 context.WithDeadline 即可。下面的例子给一个“下游最多执行 800 毫秒”的局部约束，同时保留父级更早取消的能力。

package service

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

func callDownstream(parent context.Context) error {
    // 业务只给下游 800 毫秒；WithDeadline 会自动服从 parent 更早的 deadline。
    candidate := time.Now().Add(800 * time.Millisecond)
    ctx, cancel := context.WithDeadline(parent, candidate)
    // 及时释放子上下文关联的定时器和父子引用，成功或失败都会执行。
    defer cancel()

    if err := downstream(ctx); err != nil {
        // 先判断上下文生命周期，再保留真正的业务错误。
        if errors.Is(ctx.Err(), context.DeadlineExceeded) {
            return fmt.Errorf("下游调用超时: %w", err)
        }
        if errors.Is(ctx.Err(), context.Canceled) {
            return fmt.Errorf("请求已取消: %w", err)
        }
        return err
    }
    return nil
}

func downstream(ctx context.Context) error {
    // 真实项目中应把 ctx 继续传给 HTTP、数据库或 RPC 客户端。
    select {
    case 

关键点有两个。第一，candidate 是“本次下游调用的上限”，不是对整个请求剩余时间的重新计算；第二，cancel 应在创建子上下文后立即安排，不能只在某一个成功分支里调用。

超时后如何区分父级取消、子级超时和业务错误

上下文结束后，优先检查 ctx.Err()：返回 context.DeadlineExceeded 说明某个 deadline 已经过期，返回 context.Canceled 则说明调用方或上游主动取消。若 ctx.Err() 仍为 nil，但下游返回了错误，那就是网络、参数或业务层错误，不要为了统一日志而改写成超时。

需要注意，子上下文的 Done 关闭只表达“继续做这件事已经没有意义”。下游函数必须真正监听它；如果函数内部阻塞在没有 context 版本的 API 上，deadline 不会凭空中断那段不可取消的工作。

几个容易把 deadline 写错的边界场景

如果只想表达“从现在起最多等待一段时间”，context.WithTimeout 更直观；它本质上是用当前时间加上 duration 再调用 deadline 逻辑。无论选哪一个，真正执行 I/O 的底层函数都要接收并使用这个子上下文。

常见问题

父 context 已经更早到期，为什么 WithDeadline 不报错？

这是正常语义。它仍会返回一个可用的派生上下文，只是有效 deadline 服从父级；实际调用时通过 Done 和 Err 感知结束原因。

可以用 context.Background() 绕过父级 deadline 吗？

技术上可以重新建立一条不受原请求控制的上下文，但这会破坏取消传播，通常会让请求结束后仍有后台工作。只有明确设计为独立后台任务时，才应脱离请求上下文。

收到 context.DeadlineExceeded 就一定是本层 800 毫秒到了吗？

不一定。父级 deadline、当前子级 deadline 或更深层下游的截止时间都可能先到。记录调用层级和剩余时间，才能判断是哪一层预算不足。