context.withtimeout在net/rpc中完全不生效，因其所有方法均未接收context参数；真正有效的超时需通过net.conn的setreaddeadline控制单次读操作时限，并配合连接关闭与client重建。
context.WithTimeout 在标准 net/rpc 中完全不生效——这不是你用得不对，而是它压根没读这个参数。
为什么 rpc.Client.Call 忽略 context.Context
标准库 net/rpc 的所有方法签名（比如 Call、Go）都不带 context.Context 参数。这意味着：无论你在调用前怎么 WithTimeout、WithCancel，只要没自己封装或换库，这个 ctx 就只是个被传进去又丢掉的值。
常见错误现象：
- 代码里写了
ctx, _ := context.WithTimeout(...)，但 RPC 依然卡住几十秒才返回i/o timeout - 用
select等ctx.Done()，结果超时后Call还在后台跑，goroutine 泄漏 - 误以为
http.DefaultClient的Timeout对jsonrpc.NewClient有效——其实net/rpc/jsonrpc默认走裸 TCP，不经过 HTTP transport
真正起作用的超时必须落在底层 net.Conn
对 TCP 类 RPC（gob 或 jsonrpc），唯一可靠的方式是控制连接本身的读写时限。关键点在于：不是“整个调用超时”，而是“每次系统调用（syscall）不能等太久”。
实操建议：
- 用
net.DialTimeout创建连接，控制建连阶段超时（例如5s） - 调用前必须手动设置
conn.SetReadDeadline（注意不是SetDeadline）——因为SetDeadline影响后续所有读写，而 RPC 响应可能分多次Read，中间一次超时就中断整个响应 - 每次
Call前都要重设ReadDeadline，jsonrpc.NewClient内部不会帮你重置 - 示例：
conn, _ := net.DialTimeout("tcp", "localhost:8080", 5*time.Second) conn.SetReadDeadline(time.Now().Add(8 * time.Second)) // 单次 read 最多等 8s client := jsonrpc.NewClient(conn)
用 goroutine + channel 封装 Call 的坑与补救
这是最常被抄的模式，但容易忽略两个致命问题：超时后原 Call 还在跑、底层连接没关。
正确做法要加一层清理：
- 超时触发后，立刻调用
conn.Close()（如果能拿到conn）——这会让阻塞的Read立即返回use of closed network connection - 如果用的是
rpc.NewClient(conn)，可保留该conn引用；若用rpc.Dial，需通过反射或自定义 Client 获取底层连接（不推荐） - 别只靠
time.AfterFunc关连接，必须和ctx.Done()绑定，否则 cancel 后连接还开着 - 超时后不重建 client，下次
Call很可能直接报错，生产环境建议超时后client.Close()并新建
更现实的选择：换协议或升级封装
硬改 net/rpc 源码不现实，长期维护成本高。两个务实路径：
- 迁移到
gRPC：天然支持 per-callcontext、deadline 传播、服务端自动感知取消，且生态成熟 - 用
HTTP + JSON-RPC：复用http.Client.Timeout或http.Transport配置，所有超时字段（Timeout、IdleConnTimeout、TLSHandshakeTimeout）都直接生效 - 若必须留
net/rpc，至少换用已支持context的第三方封装（如go-jsonrpc），而非标准库
最易被忽略的一点：超时从来不是单个数字的事。客户端 WithTimeout、连接层 SetReadDeadline、服务端业务逻辑里的 ctx 传递，三者缺一不可——少一层，就可能在某次网络抖动后卡死五分钟。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
