如何使用Golang实现RPC序列化与反序列化_Golang RPC数据编码与解码方法

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 即可。

服务端启动示例：

package main
import (
"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 插件机制——它们已封装好分帧、上下文、错误传播等细节。

# js # json # go # golang # 编码 # 字节 # 工具 # 栈 # ai # stream # 区别 # 标准库 # 为什么 # 封装 # Error # 字符串 # 结构体 # 无类型 # 循环 # 指针 # 接口 # Length # http # rpc # 自定义 # 客户端 # 如果你 # 序列化 # 服务端 # 重写 # 不支持 # 编解码器 # 如何用 # 如用

返回目录在线咨询

上一篇：全文小说网站制作软件,墨香阁官网入口？
下一篇：linux 不删除文件,清空文件中内容的命令

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

全网整合营销服务商

如何使用Golang实现RPC序列化与反序列化_Golang RPC数据编码与解码方法

为什么不能直接替换 rpc.Server 的编解码器？

如何用 json 实现兼容标准 rpc.Client 的服务端？

如何用 protobuf + gRPC 替代原生 net/rpc？

自定义编解码器时最容易忽略的细节

您的项目需求

为什么不能直接替换 `rpc.Server` 的编解码器？

如何用 `json` 实现兼容标准 `rpc.Client` 的服务端？

如何用 `protobuf` + `gRPC` 替代原生 `net/rpc`？