在 Go 中优化 RPC 请求超时需分层控制：客户端用 context.WithTimeout 主动中断、关闭底层 conn 强制终止；服务端设置读写 deadline；生产环境优先选用 gRPC 或 HTTP/JSON-RPC。
在 Go 中优化 RPC 请求超时，核心是**为每次调用显式设置合理的上下文超时**，避免默认无限等待或全局固定值导致的级联阻塞。Go 的 net/rpc 本身不原生支持超时，需结合 context 和底层连接控制来实现。
使用 context.WithTimeout 包裹 RPC 调用
net/rpc 的 Client.Call 和 Go 方法不接收 context，但可通过在调用前创建带超时的 context，并在 goroutine 中监听取消信号来主动中断等待：
- 启动 RPC 调用后，在单独 goroutine 中等待调用完成或 context Done
- 若 context 先结束（超时），则关闭底层连接（强制终止阻塞读）
- 推荐封装成工具函数，统一处理超时逻辑和连接清理
关闭底层 net.Conn 实现强制中断
RPC 客户端底层依赖 net.Conn 进行读写。当 context 超时时，直接调用 conn.Close() 可触发阻塞的 Read 或 Write 立即返回错误（如 use of closed network connection），从而跳出等待：
- 需通过反射或自定义 Client 获取底层 conn（例如
rpc.NewClient(conn)创建的 client 可保留 conn 引用） - 注意：多次 Close 是安全的，但需确保 conn 不被其他 goroutine 并发使用
- 避免仅依赖
time.AfterFunc关闭 conn，应与 context 生命周期绑定
服务端同步设置读写 deadline
单靠客户端超时不够——若服务端处理缓慢或卡死，客户端即使设了超时，仍可能因 TCP 层未断连而长时间挂起。应在服务端对每个连接设置读写截止时间：
立即学习“go语言免费学习笔记（深入）”；
- 在
Accept后立即对新net.Conn调用SetReadDeadline和SetWriteDeadline - deadline 应略大于预期最大处理时间（如 5s 处理 + 1s 缓冲 = 6s）
- 可结合
http.Server.ReadTimeout思路，但 RPC 需手动管理
优先考虑 gRPC 或 HTTP/JSON-RPC 替代原生 net/rpc
net/rpc 是 Go 早期标准库组件，缺乏现代超时、流控、加密等能力。生产环境建议迁移：
- gRPC：天然支持 per-call context 超时、截止时间（Deadline）、重试策略
-
HTTP + JSON-RPC：可复用
http.Client.Timeout或context，生态工具链成熟 - 若必须用
net/rpc，至少升级到基于jsonrpc或gob的封装库，部分已内置 context 支持
不复杂但容易忽略的是：超时不是只设一个数字，而是要分层控制——客户端调用超时、连接层读写 deadline、服务端业务处理限时，三者协同才能真正避免阻塞。
