最简 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 mainimport ( "net/rpc" "net" "log" )
type Args struct{ A, B int } type Reply struct{ Result int }
type Arith int
func (t Arith) Multiply(args Args, reply Reply) error { reply.Result = args.A args.B return nil }
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语言免费学习笔记（深入）”；
采用HttpClient向服务器端action请求数据，当然调用服务器端方法获取数据并不止这一种。WebService也可以为我们提供所需数据，那么什么是webService呢？，它是一种基于SAOP协议的远程调用标准，通过webservice可以将不同操作系统平台，不同语言，不同技术整合到一起。 实现Android与服务器端数据交互，我们在PC机器java客户端中，需要一些库，比如XFire,Axis2,CXF等等来支持访问WebService，但是这些库并不适合我们资源有限的android手机客户端，
- 服务端仍用
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 足够快；但只要涉及稳定性、可观测性或跨团队协作，就得接受它只是一个教学级参考实现。