Go context向下游传递截止时间的实现方式

Go 服务里，截止时间不是只在入口记录一次的日志字段，而是要跟着 context.Context 穿过 handler、服务层和下游调用。最稳妥的实现是：入口用 WithTimeout 或 WithDeadline 建立约束，每层把 ctx 作为第一个参数继续传下去，阻塞点监听 Done()，局部操作需要更紧预算时再从当前 ctx 派生子 context。

官方接口说明见 https://pkg.go.dev/context。下面只讨论截止时间的传递与边界，不展开框架选型。

把截止时间沿调用链传下去

我在排查一条“入口已经超时，下游还在工作”的链路时，最先看的是函数签名，而不是先调大超时时间。只要某一层改成 context.Background()，或者把 ctx 藏进结构体再异步使用，父级的截止时间就很容易在这一步丢失。

推荐让每一层都显式收取并转交 context：

func Handle(ctx context.Context, service *Service) error {
    // 入口只负责接收请求约束，不在中间层重新创建 Background。
    return service.Fetch(ctx)
}

func (s *Service) Fetch(ctx context.Context) error {
    // 同一个 ctx 继续交给数据访问层，截止时间自然向下游传播。
    return s.repo.Load(ctx)
}

func (r *Repository) Load(ctx context.Context) error {
    select {
    case 

这样做的价值不只是“能拿到一个时间点”。Done() 会在父级取消或截止时间到达时关闭，Err() 会进一步说明是 context.Canceled 还是 context.DeadlineExceeded。

在入口创建截止时间，在下游只读取并执行

截止时间通常由最接近请求边界的代码创建，因为那里知道整条请求的预算。创建后要立即保存 cancel，并在当前函数退出时释放它：

func HandleRequest(parent context.Context, service *Service) error {
    // 这里给整条请求设置 200ms 上限，实际项目可由入口策略计算。
    ctx, cancel := context.WithTimeout(parent, 200*time.Millisecond)
    defer cancel() // 释放定时器和派生 context 关联的资源。

    if deadline, ok := ctx.Deadline(); ok {
        // 只记录相对剩余时间，避免把绝对时间当成新的超时配置。
        log.Printf("request budget left: %s", time.Until(deadline).Round(time.Millisecond))
    }
    return service.Fetch(ctx)
}

下游如果支持 context，就把它原样传给客户端或数据库方法；如果是自定义阻塞逻辑，则至少在等待和发送结果的位置监听 ctx.Done()。不要在每层都固定写一个新的 200ms，因为那会把“整条链路预算”误解成“每层都拥有一份独立预算”。

子调用设置更短预算时如何保持父级约束

局部操作可以比整条请求更早结束。例如请求还剩 150ms，但查询只希望最多占 50ms，可以从当前 ctx 派生：

func (s *Service) Fetch(ctx context.Context) error {
    // 局部预算只能从当前 ctx 派生，不能从 Background 重新起表。
    queryCtx, cancel := context.WithTimeout(ctx, 50*time.Millisecond)
    defer cancel()

    return s.repo.Load(queryCtx)
}

WithTimeout 不会把父级截止时间延后：如果父级只剩 20ms，子 context 实际上也只能活 20ms。这个规则让调用链的最早约束优先生效。图中把父子 context、Deadline() 和 Done() 的关系画在同一张边界图里，重点是“子预算更短，父取消仍然可达”。

常见误区与排查清单

排查时可以在每个边界记录 time.Until(deadline)、业务阶段和 ctx.Err()。这些信息比单独记录“请求耗时”更容易判断：是预算本来就太短、某层没有传递，还是下游在取消后仍未停止。

常见问题

下游函数能不能把 context 保存到结构体里？

一般不要这样做。context 应作为调用参数传入，才能明确它属于哪一次请求；结构体长期保存容易把已经过期的截止时间带到下一次调用。

父 context 没有截止时间时怎么办？

先确认这是有意设计还是入口漏配。没有截止时间的 ctx 仍可传递取消信号，但对外部请求、数据库和 RPC 通常应在边界设置明确预算。

收到 DeadlineExceeded 后还要继续重试吗？

不要在原 ctx 已经结束后盲目重试。先判断剩余业务价值；若确实需要重试，应由更上层重新规划总预算，并把新的可用 ctx 传入。