net/rpc 默认只支持导出方法，因反射无法访问小写开头的未导出方法；方法签名须为 func(t, args, *reply) Error；默认 gob 编码不跨语言；超时需用 context 包裹调用。
为什么 net/rpc 默认只支持导出方法
因为 Go 的 RPC 服务端靠反射遍历结构体方法，未导出（小写开头）的方法在包外不可见，server.register 根本看不到它们，调用时直接报 method not found。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 服务端注册的结构体字段和方法名必须首字母大写（如
User、GetInfo） - 方法签名必须严格为
func(*T, *Args, *Reply) error，三个参数都得是指针，且第三个是输出结果 - 如果传值类型（如
int）当*Args，会 panic：「rpc: method has wrong number of ins」
gob 编解码限制导致跨语言调用失败
net/rpc 默认用 gob 序列化，它依赖 Go 类型元信息，其他语言根本解析不了 —— 这不是 bug，是设计使然。想和 Python/js 通信？别用标准库 net/rpc，换 jsonrpc2 或 gRPC。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 纯 Go 内部通信可用默认
gob，但客户端和服务端 Struct 字段标签（如json:"id"）不影响gob，它只看字段名和顺序 - 若手动换
json编解码，需调用rpc.NewServer()后用server.RegisterCodec，且客户端也得配对使用jsonrpc.NewClient - 常见错误现象：
unexpected EOF或invalid character，大概率是客户端没切 codec，还在发 gob 流
阻塞式调用下超时控制必须靠 context 手动包一层
net/rpc 的 Client.Call 和 Go 方法本身不接受 context.Context，超时只能靠外部控制。直接设 conn.SetDeadline 不行 —— RPC 是多请求复用连接的，改 deadline 会影响后续调用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
context.WithTimeout包住整个调用逻辑，再起 goroutine +select等待结果或超时 - 不要试图给底层
net.Conn设读写 deadline，RPC 消息头+体是分步读的，中间 deadline 到期会导致粘包错乱 - 示例关键片段：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second) defer cancel() done := make(chan *rpc.Call, 1) go func() { done <- client.Go("User.GetInfo", &args, &reply, nil) }() select { case call := <-done: if call.Error != nil { /* 处理错误 */ } case <-ctx.Done(): /* 超时，但注意：call 可能还在跑，无法取消 */ }
服务端启动后没监听到请求？检查 http.Serve 是否误用了
net/rpc 本身不带 HTTP 服务逻辑，但文档里那个 http.Serve 示例容易误导人 —— 它只是把 RPC handler 挂到 HTTP server 上，走的是 HTTP POST + gob body。如果你没配好 HTTP router 或忘了 http.Handle，请求就静默丢弃，连日志都没有。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 最简 TCP 直连方式：用
rpc.ServeConn配net.Listen，绕过 HTTP 层，调试更直接 - 如果坚持走 HTTP，必须显式注册：
http.Handle("/RPC2", rpc.DefaultServer)，路径名不能错，且客户端 URL 得匹配（如http://localhost:8080/RPC2） - 常见错误现象：curl 测试返回 404 或空响应，tcpdump 看到 SYN-ACK 但无数据 —— 八成是 handler 没挂对路径
真正麻烦的从来不是写通一次调用，而是当多个客户端并发注册、方法返回 error 但 reply 已部分写入、或者服务端 panic 后连接卡死 —— 这些边界在标准库里全得自己兜底。