根本原因是net/rpc包设计上不支持context.Context，所有方法签名均无context参数，故context.WithTimeout无效；真实超时需通过net.Conn的SetDeadline等底层控制。
Go RPC调用里，context.WithTimeout 不生效？
根本原因不是 Context 没传，而是标准 net/rpc 包压根不读取 context.Context。它从设计上就和 Context 无关——所有方法签名里都没有 context.Context 参数，比如 Client.Call 的签名为 func (client *Client) Call(serviceMethod string, args interface{}, reply interface{}) error。
所以你往任何地方塞 context.WithTimeout，只要没自己封装或换库，它就只是个摆设。
- 别在
rpc.Client调用前单独起 goroutine + select 等待，那会绕过 RPC 底层连接/读写超时，容易卡死 - 别依赖 HTTP transport 层的 timeout（比如用
http.DefaultClient封装 RPC），net/rpc默认走 TCP，不经过 HTTP - 真实生效的超时必须落在连接建立、发送请求、等待响应这三个阶段，且得靠底层 Conn 或自定义 Codec 控制
用 net/rpc/jsonrpc 时如何加连接和读写超时
jsonrpc.NewClient 和 jsonrpc.NewClientCodec 都不接受 context.Context，但你可以控制它背后的 net.Conn。关键是在 Dial 阶段注入超时逻辑。
示例：用 net.DialTimeout 创建带连接超时的 Conn，再手动设置读写 deadline：
立即学习“go语言免费学习笔记（深入）”；
conn, err := net.DialTimeout("tcp", "localhost:8080", 5*time.Second)
if err != nil {
return err
}
// 设置每次读/写的最大等待时间（注意：是每次 syscall，不是整个 RPC 调用）
conn.SetDeadline(time.Now().Add(10 * time.Second))-
SetDeadline影响的是单次Read/Write，对长响应或大 payload 容易误杀；更稳妥的是用SetReadDeadline+SetWriteDeadline分开控 - 如果服务端响应慢但分块发数据，
SetDeadline可能导致中间 read 成功、最后 read 超时，错误信息是read tcp ...: i/o timeout -
jsonrpc.NewClient内部不会重置 deadline，所以每个 RPC 调用前都得手动调一次conn.SetReadDeadline
想真正用上 context.Context？换 gRPC 或自己包一层
原生 net/rpc 没法支持 context.WithCancel / WithTimeout 的传播，硬改源码不现实。两个务实选择：
- 迁移到
gRPC：天然支持context.Context透传，ctx会自动送到服务端，服务端可用ctx.Done()做取消感知 - 自己封装
rpc.Client：把Call方法改成接收context.Context，内部启动 goroutine 执行调用 + select 等待 ctx Done，同时用conn.SetReadDeadline控制底层 IO
后者要注意：goroutine 泄漏风险高。如果 ctx 已 cancel 但 Conn 还在 read，得确保有机制能中断阻塞的系统调用（Linux 上可关掉 Conn，Windows 需用 SetDeadline 配合）。
rpc.Server 端没法响应 context.DeadlineExceeded？
没错。net/rpc 的 Server.ServeConn 或 Server.ServeHTTP 完全不知道客户端有没有传 Context，更不会把超时信号转成 error 返回。服务端看到的永远是“连接突然断开”或“读不到完整请求”，错误日志通常是 io.EOF 或 connection reset by peer。
这意味着：你不能在服务端靠检查 ctx.Err() == context.DeadlineExceeded 来做差异化处理（比如跳过日志、释放资源），因为根本没有 ctx。
- 若需服务端感知超时，必须靠客户端主动发取消通知（比如额外定义一个 Cancel 方法），或改用 gRPC
- 服务端唯一可控的是
Handler函数内自己检查耗时，但无法知道客户端是否已放弃，纯属“尽力而为” - 别在 Handler 里用
time.AfterFunc模拟超时——这解决不了客户端早已断连的问题，还可能引发 panic
Context Deadline 在 Go RPC 里不是开关，而是需要整条链路配合的契约。缺一环，就只剩表层的连接超时，没有真正的请求级生命周期管理。
