超时控制是分布式系统里最基础也最容易踩坑的一环。Golang从语言层面提供了context包和select机制，让RPC调用的超时处理变得比较优雅，但要用对并不简单。本文从基础用法讲到进阶实践，配合完整代码示例，把Golang中实现RPC超时控制的几种常见方式彻底讲清楚。
为什么RPC必须设置超时
先看一个真实的故障场景：某服务的下游数据库偶发慢查询，一次请求耗时30秒。由于RPC客户端没有设置超时，调用方协程全部阻塞在这个请求上，随着流量进来，协程数量从几百涨到几万，内存被打满，最终整个服务雪崩。这类故障的根源不是下游慢，而是上游对下游的故障没有隔离手段。
超时控制的核心价值在于故障隔离。它保证单个下游请求的失败只影响当前这一次调用，调用方可以在限定时间内返回错误、释放资源，不至于让故障向上游蔓延。Go语言中实现这一点的标准工具是context包，几乎所有的主流RPC框架（gRPC、kratos、go-zero）都基于它来实现超时传递。
使用context.WithTimeout实现标准超时
context.WithTimeout是最常用的方式。它返回一个带截止时间的子context和一个取消函数，当超时时间到达后，ctx会被自动取消，所有监听该ctx的操作都会收到取消信号。
package main
import (
"context"
"fmt"
"time"
)
func rpcCall(ctx context.Context, req string) (string, error) {
// 模拟一个耗时2秒的远程调用
select {
case <-time.After(2 * time.Second):
return "response for " + req, nil
case <-ctx.Done():
return "", ctx.Err() // 返回 context.DeadlineExceeded
}
}
func main() {
// 设置500毫秒超时
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
start := time.Now()
resp, err := rpcCall(ctx, "hello")
fmt.Printf("耗时: %v, 错误: %v, 响应: %q\n", time.Since(start), err, resp)
}上面这段代码会输出context deadline exceeded错误，耗时约500毫秒而不是2秒。有两个细节必须注意：第一，defer cancel()不能省，即使函数提前返回也要释放资源，否则context内部资源要等到超时才能回收；第二，被调用方内部一定要用select监听ctx.Done()，否则超时信号发出来了却没人接收，goroutine照样会阻塞到操作结束。
WithTimeout和WithDeadline本质是同一个东西，前者传相对时长，后者传绝对时间点。一般业务代码用WithTimeout更直观，而在需要跨服务传递截止时间的场景下用WithDeadline更合适，比如把上游传来的deadline直接换算成本地的绝对时间点往下传。
基于select通道的手动超时控制
如果不方便改造函数签名为context形式，也可以用channel配合select手动实现。做法是把调用放到独立goroutine中执行，主流程用select同时监听结果通道和超时通道。
func callWithTimeout(timeout time.Duration) (string, error) {
resultCh := make(chan string, 1) // 缓冲为1，防止goroutine泄漏
go func() {
resultCh <- doSlowRPC() // 假设这是一个慢调用
}()
select {
case res := <-resultCh:
return res, nil
case <-time.After(timeout):
return "", fmt.Errorf("rpc timeout after %v", timeout)
}
}这里有个关键点：resultCh必须带缓冲。如果不带缓冲，超时发生后主流程不再读取通道，执行doSlowRPC的goroutine会永远阻塞在发送语句上，造成泄漏。带缓冲为1之后，即使没人接收，goroutine也能完成发送并退出。不过要注意，这种做法只是不再等待结果了，底层连接上的操作是否真的停止，取决于doSlowRPC内部是否支持中断，这也是context方案更被推荐的原因。
客户端与服务端两侧的超时设置
完整的超时控制应该覆盖链路两端。客户端超时决定调用方愿意等多久，服务端超时决定处理方最多执行多久，两者通常都要设置，且服务端超时一般要略小于客户端超时，留出网络往返的余量。
以gRPC为例，客户端这样设置：
conn, err := grpc.Dial("127.0.0.1:9000",
grpc.WithTransportCredentials(insecure.NewCredentials()),
)
if err != nil {
log.Fatal(err)
}
ctx, cancel := context.WithTimeout(context.Background(), 800*time.Millisecond)
defer cancel()
resp, err := pb.NewUserServiceClient(conn).GetUser(ctx, &pb.GetUserRequest{Id: 1})gRPC客户端会自动把deadline编码进grpc-timeout这个metadata头部传给服务端，服务端的handler收到的ctx已经带上了剩余时间，处理逻辑里只要正常响应ctx.Done()就能实现级联超时。如果自己手写RPC，则需要显式地把deadline放进请求头部，例如定义deadline字段携带Unix纳秒时间戳，服务端取出后与当前时间比较，超时就直接返回错误。
常见坑与实践建议
第一个坑是goroutine泄漏。前面已经提到，超时返回不等于底层操作被取消，务必确认被调用的函数内部监听了取消信号。可以在压测后用runtime.NumGoroutine()观察协程数是否持续增长来排查。
第二个坑是超时时间一刀切。一次请求内部往往串联多个下游调用，如果每个都设1秒，最坏总耗时可能是N秒，早就超过上游的容忍度。正确做法是从入口处生成一个总deadline，每往下调用一层用context.WithTimeout派生子context，剩余时间逐层递减，形成金字塔式的超时预算分配。核心数据库、缓存等关键依赖可以分到更大份额，非关键路径分到更小的份额甚至直接放弃。
第三个坑是把超时值硬编码在代码里。更合理的做法是放到配置中心，方便线上动态调整。最后再补充一点：超时要配合重试策略使用才有意义，注意给重试设置次数上限和退避间隔，否则一次抖动可能引发重试风暴，反而加速服务崩溃。把超时、取消、重试三者组合好，服务的稳定性就有了最基本的保障。