Go rpc.Client 默认不支持超时，需用 context.WithTimeout + select 封装实现；或改用 jsonrpc 配合 http.Transport 超时配置；生产环境推荐迁移到 gRPC 或 go-kit 等成熟框架。
Go rpc.Client 默认不支持超时，必须手动封装上下文
Go 标准库的 net/rpc 包本身不感知 context.Context，所有调用（如 Call、Go）都是阻塞式且无原生超时机制。直接在 HTTP 或 TCP 连接层设 Deadline 也不可靠——它只控制底层连接建立或读写，无法中断正在执行的 RPC 方法逻辑（比如服务端卡在数据库查询中）。
实际可行方案是：在客户端发起调用前，用 context.WithTimeout 创建带截止时间的上下文，再通过自定义封装（如包装 Client 或改用 jsonrpc2 等第三方库）将上下文传递进去。标准 rpc.Client 不接受 context 参数，所以必须自己做一层适配。
用 context.WithTimeout + select 手动实现非阻塞调用
这是最轻量、无需引入额外依赖的做法。核心思路是启动一个 goroutine 执行 client.Call，主 goroutine 用 select 等待结果或超时信号。
- 超时后需主动关闭底层连接（
conn.Close()），否则资源泄漏 - 服务端不会因客户端断连而自动中止处理，仅避免后续响应被接收
- 注意
Call的reply参数必须是指针，且不能在超时分支里访问，否则可能 panic
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel()done := make(chan *rpc.Call, 1) go func() { call := client.Go("Arith.Multiply", args, &reply, nil) done <- call }()
select { case <-ctx.Done(): conn.Close() // 关闭底层 net.Conn return errors.New("RPC call timeout") case call := <-done: if call.Error != nil { return call.Error } return nil }
改用 golang.org/x/net/rpc/jsonrpc 并配合 http.Transport 控制连接级超时
如果你用的是 JSON-RPC over HTTP（即通过 jsonrpc.NewClient 连接 HTTP 后端），可把底层 http.Client 的 Transport 配置为带超时的实例。这能控制 DNS 解析、连接建立、TLS 握手、请求头发送、响应头读取等阶段，但对服务端处理耗时无效。
立即学习“go语言免费学习笔记（深入）”；
-
Transport.DialContext控制建连超时（推荐设为1s） -
Transport.ResponseHeaderTimeout控制从发送完请求到收到响应头的时间（推荐3s） - 仍需在业务层加 context 超时兜底，防止服务端 hang 住
transport := &http.Transport{
DialContext: func(ctx context.Context, network, addr string) (net.Conn, error) {
return net.DialTimeout(network, addr, 1*time.Second)
},
ResponseHeaderTimeout: 3 * time.Second,
}
client := jsonrpc.NewClient(http.DefaultClient)生产环境建议：直接迁移到 gRPC 或使用 kit/transport 等成熟 RPC 框架
标准 net/rpc 缺乏中间件、超时、重试、熔断、指标埋点等能力，维护成本高。gRPC 原生支持 context 透传，所有方法签名都带 ctx，服务端也能通过 ctx.Err() 感知取消；go-kit 的 transport/http 或 transport/grpc 层也内置了完整的超时与错误分类逻辑。
硬要在 net/rpc 上做健壮超时，最终往往要重复造轮子：封装 client、管理连接池、区分网络错误与业务错误、记录 slow log……这些在 gRPC 或 Kit 里已是默认行为。
真正容易被忽略的是：超时值不是越小越好。设成 100ms 可能导致大量误超时（尤其跨机房或负载高时），而设成 30s 又会让故障扩散更久。建议按 P99 延迟 × 2～3 倍设定，并配合服务端设置 context.Deadline 主动退出长耗时操作。
