net/rpc 默认用 gob，不支持跨语言；换 JSON 需用 jsonrpc 包并调用 jsonrpc.ServeConn；换 protobuf 应直接用 gRPC；自定义 ServerCodec 必须处理分帧、Header 解析和错误传播。
Go 标准库的 net/rpc 默认使用 gob 编码，不支持跨语言、不兼容 JSON 或 Protocol Buffers——如果你需要自定义序列化（比如用 json 或 protobuf），必须绕过默认机制，自己接管编解码流程。
为什么不能直接替换 rpc.Server 的编解码器？
标准 rpc.Server 和 rpc.Client 将编码/解码深度耦合在 rpc.Server.ServeCodec 和 rpc.NewClientWithCodec 中，底层依赖 rpc.ServerCodec 接口。它要求你同时实现 ReadRequestHeader/ReadRequestBody 和 WriteResponse 等方法，不能只换一个序列化格式。
常见错误是试图“简单替换 gob 为 json”，结果发现请求头读不出来、响应乱序、或连接直接断开——因为 json 没有 gob 那样的类型元信息和流式分帧能力。
-
gob自带类型描述、支持指针/接口/循环引用，且天然适配 Go 运行时；json是纯文本、无类型、需显式结构体标签 - RPC 协议不是“发一串 JSON 就完事”，它需要严格区分 header（含方法名、序列号）和 body（参数），而
json不提供内置分界机制 - 标准
rpc/jsonrpc包只是对gob编解码逻辑的重写，并非“用encoding/json替代gob”——它仍遵循 RPC 帧格式约定
如何用 json 实现兼容标准 rpc.Client 的服务端？
使用 net/rpc/jsonrpc 是最轻量、最兼容的方式：它复用了标准 rpc 的注册与调用逻辑，仅替换底层编解码器。客户端无需改代码，只要把 rpc.NewClient 换成 jsonrpc.NewClient 即可。
立即学习“go语言免费学习笔记（深入）”；
服务端启动示例：
package mainimport ( "net" "net/rpc" "net/rpc/jsonrpc" )
type Args struct{ A, B int } type Quotient struct{ Quo, Rem int }
type Arith int
func (t Arith) Multiply(args Args, reply int) error { reply = args.A * args.B return nil }
func main() { rpc.Register(new(Arith)) listener, := net.Listen("tcp", ":1234") for { conn, := listener.Accept() go jsonrpc.ServeConn(conn) // ← 关键：用 jsonrpc.ServeConn 替代 rpc.ServeConn } }
注意点：
- 必须用
jsonrpc.ServeConn启动连接，不能用rpc.ServeConn - 客户端必须用
jsonrpc.NewClient或jsonrpc.Dial，否则会因帧格式不匹配而报invalid character错误 - 结构体字段必须首字母大写（导出），且建议加
json:标签以控制 key 名
如何用 protobuf + gRPC 替代原生 net/rpc？
如果你真正想要的是高性能、跨语言、带 IDL 的 RPC，不要硬改 net/rpc，直接用 gRPC-Go。它本质是基于 HTTP/2 的二进制 RPC 框架，protobuf 是其默认序列化协议，天然支持 streaming、拦截器、超时、认证等。
关键区别：
-
net/rpc是 TCP + 自定义二进制帧（gob）或 JSON 帧；gRPC是 HTTP/2 +protobuf+gRPC-encoding（length-delimited） -
gRPC要求先写.proto文件生成 Go 代码；net/rpc直接注册结构体和方法 - 没有
gRPC服务端，protobuf只是序列化工具——你仍需自己设计传输层（比如用net.Conn+ 自定义分帧），这极易出错
所以，除非你有强约束（如必须复用现有 net/rpc 客户端、不能引入新协议栈），否则别尝试“给 net/rpc 换 protobuf 底层”。真要这么做，得完整实现 rpc.ServerCodec，包括：ReadRequestHeader 解析 method/service/seq，ReadRequestBody 用 proto.Unmarshal，还要处理 length-prefix framing——这已接近重写整个 RPC 栈。
自定义编解码器时最容易忽略的细节
当你实现自己的 rpc.ServerCodec，以下三点几乎必踩坑：
- TCP 是字节流，没有消息边界——必须自己加长度前缀（如 4 字节 uint32 表示后续 payload 长度），否则
ReadRequestBody会阻塞或读错数据 -
ReadRequestHeader必须严格按 RPC 协议解析出ServiceMethod字符串（格式为"Service.Method"）和Seq（请求序号），漏掉任一字段会导致客户端永远收不到响应 -
WriteResponse的err参数不能忽略：如果业务逻辑返回 error，必须写入 response body 并设置ErrorResponse标志，否则客户端Call会卡死或 panic
真正稳定的自定义方案，往往不是从零写 ServerCodec，而是基于 gRPC 的 Codec 接口或 go-micro 的 codec 插件机制——它们已封装好分帧、上下文、错误传播等细节。
