最推荐用 context.Context 控制 RPC 调用生命周期：连接阶段用 DialContext 建立带超时的 net.Conn，调用前检查 ctx.Err()，gRPC 原生支持 ctx 透传，超时后必须显式 Close 并 defer cancel()。
在 Go 中处理 RPC 请求超时，最推荐的方式是使用 context.Context 控制调用生命周期，而不是依赖客户端或服务端的硬编码超时设置。Go 标准库的 net/rpc 本身不直接支持 context，但通过封装底层连接（如 net.Dial）并结合 context.WithTimeout 或 context.WithDeadline，就能实现可靠、可取消的 RPC 调用。
用 Context 包装底层连接（关键一步）
标准 rpc.Client 的 rpc.Dial 等函数不接受 context，因此需手动控制连接建立阶段的超时。常见做法是用 context.WithTimeout 配合 net.Dialer.DialContext 创建带超时的连接：
- 创建带超时的 context：例如
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - 用
&net.Dialer{Timeout: 5 * time.Second}或更推荐的dialer.DialContext(ctx, "tcp", addr)建立连接 - 将得到的
net.Conn传给rpc.NewClient(conn)，这样连接阶段就受 context 约束
调用方法时主动检查 Context 状态
RPC 方法执行本身（即 client.Call）是同步阻塞的，无法被 context 中断 —— 但你可以提前判断 context 是否已取消或超时，避免发起无效调用：
- 在
Call前加if err := ctx.Err(); err != nil { return err } - 对长时间运行的 RPC，可在回调中定期检查
ctx.Done()（适用于自定义流式或分步 RPC 场景） - 注意：
ctx.Err()在超时后返回context.DeadlineExceeded，可据此区分超时和其他错误
结合 HTTP-based RPC（如 gRPC）更原生支持 Context
如果你使用的是 gRPC（Go 官方推荐的现代 RPC 框架），context 支持是第一等公民：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 每个 RPC 方法签名都以
ctx context.Context为第一个参数，例如client.GetUser(ctx, &pb.GetUserRequest{Id: 123}) - 超时直接由 context 控制：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) - 服务端也能通过
ctx.Done()感知调用中断，及时释放资源、退出 goroutine
清理与资源释放不可少
无论用哪种方式，超时后必须显式关闭 client 和底层连接，防止 goroutine 泄漏或文件描述符耗尽：
- 调用
client.Close()（net/rpc）或conn.Close()（gRPC 的*grpc.ClientConn） - 建议用
defer cancel()配合defer client.Close()组合确保执行 - 如果 RPC 调用嵌套在循环或高并发中，务必为每次调用新建独立 context，避免相互干扰
基本上就这些。核心逻辑很清晰：连接层用 Context 控制建立，调用前做状态检查，现代框架（如 gRPC）直接透传 Context，最后别忘了 cleanup。不复杂但容易忽略。
