Go net/rpc 默认无超时，需用 context.WithTimeout 封装 Call 实现超时控制，或改用 gRPC；HTTP/JSON-RPC 还需分层设置连接、响应头、读取超时。
Go net/rpc 默认不支持超时，必须自己加
Go 标准库的 net/rpc 包本身没有超时参数，client.Call 会一直阻塞直到服务端返回或连接断开。这意味着一旦后端卡住、网络抖动或服务崩溃，调用方线程就挂死了，SLA 直接崩盘。
实操上只有两个可靠路径：要么换用带上下文支持的 RPC 框架（如 gRPC），要么在 net/rpc 上手动套一层超时控制。后者常见但容易出错：
- 别用
time.AfterFunc+go启动 goroutine 去 cancel —— 竞态难测，且无法回收已发出去但未响应的请求 - 正确做法是用
context.WithTimeout包裹整个调用流程，再传给自定义的封装函数 - 注意：标准
*rpc.Client不接受context.Context，必须自己封装一个带 context 的调用器，内部用select等待Call完成或超时
用 context.WithTimeout 封装 rpc.Client.Call 的最小可行写法
核心不是改 client，而是把阻塞调用变成可取消的异步等待。下面这段代码能直接复用在大多数微服务中：
func CallWithContext(client *rpc.Client, serviceMethod string, args interface{}, reply interface{}, timeout time.Duration) error {
ctx, cancel := context.WithTimeout(context.Background(), timeout)
defer cancel()
<pre class="brush:php;toolbar:false;">done := make(chan *rpc.Call, 1)
go func() {
client.Call(serviceMethod, args, reply)
done <- nil
}()
select {
case <-done:
return nil
case <-ctx.Done():
return ctx.Err() // 返回 context.DeadlineExceeded 或 context.Canceled
}}
立即学习“go语言免费学习笔记（深入）”；
关键点：
-
done通道只收一个*rpc.Call，但实际我们只关心是否完成，所以填nil即可 - 不能用
client.Go替代client.Call——Go是异步发起，但它的Donechannel 一样不带超时，仍需额外 select - 这个封装不侵入原有业务逻辑，所有
client.Call(...)可一键替换成CallWithContext(...)
gRPC 替代方案里 context.WithTimeout 是刚需，不是可选项
如果你用的是 gRPC（更推荐用于微服务），那 context.WithTimeout 是每次调用必传的参数，否则默认无超时。比如：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
resp, err := client.GetUser(ctx, &pb.GetUserRequest{Id: 123})这里容易踩的坑：
- 超时时间设太短：gRPC 的 header 传输、TLS 握手、流控排队都会吃掉几毫秒，100ms 超时大概率误杀正常请求
- 超时设太长：单个慢请求会拖垮整个 goroutine 池，尤其在高并发下形成雪崩
- 不要在 handler 里重设 context 超时 —— 新 context 和原 RPC 生命周期脱钩，服务端可能还在处理，客户端却已放弃
HTTP/JSON-RPC 场景下，超时要分层设：连接、读、写三者独立
很多 Go 微服务用 HTTP 承载 JSON-RPC（比如用 net/http + jsonrpc2 库），这时超时不能只靠一次 context.WithTimeout 解决。
真正影响 SLA 的是三个阶段：
- 建立 TCP 连接耗时 —— 控制在
http.Transport.DialContext里设Timeout - 发送请求体耗时 —— 由
http.Transport.ResponseHeaderTimeout管理（从发出到收到 header） - 读取完整 body 耗时 —— 用
http.Transport.ReadTimeout（注意：Go 1.19+ 已废弃，改用http.Client.Timeout或更细粒度的context）
漏掉任意一层，都可能出现“看着没超时，其实卡在连不上”或“header 收到了，body 死活不来”的假象。
复杂点在于：这些超时值得根据链路位置动态调整。网关层可以设得松些（比如 3s），下游核心服务必须压到 800ms 内——而这点，光看代码很难发现，得靠真实压测里的 P99 分位日志才能定位。
