Go context 超时控制：把 deadline 传到每个下游调用

没有超时的并发就像没有刹车的车。请求入口已经超时，内部 goroutine 还在查数据库、等 HTTP 响应，这会持续消耗连接池和内存。context 的价值，就是让 deadline 成为调用链的一部分。

入口设置总预算

总预算应该从用户体验和服务 SLO 反推。例如接口希望 1 秒内返回，可以给业务处理 800ms，留下序列化和网络抖动的余量。不要在每个下游随意设置互相矛盾的 timeout。

下游分配子预算

并不是所有下游都能拿到完整预算。缓存可以 50ms，数据库可以 200ms，外部 HTTP 可以 300ms。子预算应该小于父 context 的剩余时间。

取消不是错误噪音

context.Canceled 和 DeadlineExceeded 应该被统计，但不一定都算业务错误。用户主动断开、上游超时和本服务处理超时要区别分析。

代码示例

func Query(ctx context.Context, id int64) (*DTO, error) {
    dbCtx, cancel := context.WithTimeout(ctx, 200*time.Millisecond)
    defer cancel()

    row := db.QueryRowContext(dbCtx, "select name from user where id=?", id)
    if err := row.Err(); err != nil {
        return nil, err
    }
    return dto, nil
}

上线检查

• 入口 context 不被替换为 context.Background。
• 数据库、HTTP、缓存都使用支持 context 的 API。
• 日志里区分 canceled 和 deadline exceeded。