最简 net/rpc 调用需服务端用 rpc.RegisterName("Arith", new(Arith)) 注册、监听 TCP 并 Accept，客户端用 client.Call("Arith.Multiply", &args, &reply)；方法签名必须为 func(T, Arg, *Reply) error，且字段全导出。
Go 标准库 net/rpc 怎么跑通一个最简调用
标准库的 net/rpc 默认基于 HTTP 或 TCP 传输，使用 Go 自带的 gob 编码。它不依赖外部框架，但要求服务端和客户端类型定义严格一致，且只支持导出（首字母大写）的方法。
关键约束：func (t *T) MethodName(argType *Arg, replyType *Reply) error 必须满足：接收者是指针、两个参数都是指针、返回 error。
- 服务端注册时必须用
rpc.RegisterName("MyService", &MyService{})显式命名，否则客户端无法按名查找 - 客户端连接后要先调用
client.Call("MyService.MethodName", &arg, &reply)，方法名是"服务名.方法名"字符串，不是反射自动推导 - 如果服务端没监听或客户端 dial 超时，
Call会直接返回rpc: no such service类错误，不是网络层错误 —— 这说明服务未注册或名称不匹配，不是连不上
package main
<p>import (
"net/rpc"
"net"
"log"
)</p><p>type Args struct{ A, B int }
type Reply struct{ Result int }</p><p>type Arith int</p><p>func (t <em>Arith) Multiply(args </em>Args, reply <em>Reply) error {
reply.Result = args.A </em> args.B
return nil
}</p><p>func main() {
rpc.RegisterName("Arith", new(Arith))
listener, _ := net.Listen("tcp", ":1234")
rpc.Accept(listener)
}为什么用 jsonrpc 替代默认 gob 编码
gob 是 Go 专属二进制格式，跨语言调用完全不可行；而 jsonrpc 协议天然兼容 Python、Node.js、curl 等任意能发 HTTP POST 的客户端。Go 标准库提供了 net/rpc/jsonrpc 包，只需替换连接建立方式。
立即学习“go语言免费学习笔记（深入）”；
- 服务端仍用
rpc.Register，但监听后需用jsonrpc.ServeConn(conn)处理单个连接，或包装成 HTTP handler - 客户端不能直接用
rpc.Dial，得用jsonrpc.Dial("tcp", "localhost:1234") - HTTP 场景下，建议用
http.Serve+rpc.HTTPHandler暴露/rpc端点，此时客户端可用curl -X POST -H "Content-Type: application/json" --data '{"method":"Arith.Multiply","params":[{"A":3,"B":4}],"id":1}' http://localhost:8080/rpc
rpc.Client.Call 返回 rpc: can't find method 怎么排查
这个错误和网络无关，只表示服务端没找到对应方法。常见原因不是拼写错，而是结构体字段未导出或参数类型不匹配。
- 检查
Args和Reply中所有字段是否首字母大写（如A int✅，a int❌） - 确认客户端传入的
args是指针，且类型与服务端签名中声明的*Args完全一致（包括包路径，比如myproj.Args和main.Args视为不同类型） - 服务端若用
rpc.Register(&MyService{})，则方法名前缀是MyService.MethodName；若用rpc.RegisterName("X", &MyService{})，则必须用X.MethodName - 如果服务端重启过但客户端复用旧
*rpc.Client，可能因底层连接断开导致后续调用静默失败 —— 建议每次调用前检查client.Go的返回值或封装重连逻辑
生产环境为什么不推荐裸用 net/rpc
它缺少超时控制、上下文传播、中间件、服务发现、负载均衡等现代 RPC 必备能力。例如 client.Call 没有 context.Context 参数，无法主动取消；也没有内置重试或熔断。
- 超时只能靠底层连接设置（如
net.DialTimeout），但业务逻辑超时无法单独控制 - 日志、鉴权、链路追踪需手动在每个方法里加，无法统一拦截
- 服务部署多个实例时，客户端得自己维护节点列表并做轮询 —— 标准库不提供服务注册/发现机制
- 真正落地的项目基本都转向
gRPC（基于 HTTP/2 + Protocol Buffers）或轻量方案如kitex、kratos，它们把序列化、传输、错误码、元数据都标准化了
如果只是内部小工具或 PoC，net/rpc 足够快；但只要涉及稳定性、可观测性或跨团队协作，就得接受它只是一个教学级参考实现。
