Go 的 net/rpc 默认用 gob 序列化，是 Go 原生二进制格式，仅支持同构 Go 系统通信；跨语言会失败，常见错误如 rpc: can't find service method 或 EOF；切换 JSON-RPC 需用 jsonrpc 包并显式调用 ServeConn 和 Dial。
Go 的 net/rpc 默认用什么序列化？
默认用 gob，不是 JSON、不是 Protobuf，是 Go 原生二进制格式。它只保证 Go 客户端和服务端之间能互通，跨语言调用会直接失败。
常见错误现象：rpc: can't find service method 或连接后立刻 EOF，往往是因为客户端用了 JSON 编码，服务端却在等 gob 流。
-
gob要求结构体字段首字母大写（即导出），否则序列化时忽略 - 不支持循环引用，也不支持
func、chan、unsafe.Pointer等类型 - 服务端注册方法签名必须是
func(*T, *S) error形式，其中T是接收参数，S是响应结果
如何切换成 JSON-RPC？
用 net/rpc/jsonrpc 替代默认的 gob 编解码器，但注意：它只是把 gob 换成 json，底层仍是 net/rpc 协议，不是 HTTP+JSON 的 REST 风格。
服务端需显式包装 listener：
立即学习“go语言免费学习笔记（深入）”；
listener, _ := net.Listen("tcp", ":8080")
for {
conn, _ := listener.Accept()
go jsonrpc.ServeConn(conn) // ← 关键：用 ServeConn 而非 HandleHTTP
}
客户端连接时也要用 jsonrpc.Dial：
client, err := jsonrpc.Dial("tcp", "localhost:8080")
if err != nil {
log.Fatal(err)
}
var reply string
err = client.Call("Arith.Multiply", &args, &reply)
- JSON 不支持
int64在 32 位环境下的精确传输（JavaScript number 最大安全整数是2^53-1） - 空结构体、nil slice、零值字段在 JSON 中可能被省略，而
gob会保留 - 没有标准 HTTP 头或状态码，调试时不能用 curl 直接发请求
为什么别在生产环境硬套 net/rpc？
它定位是「同构 Go 系统内部轻量通信」，不是通用 RPC 框架。真实项目里容易踩的坑包括：
- 连接复用弱：每个
rpc.Client对应一条 TCP 连接，高并发下易耗尽 fd - 超时控制粒度粗：只能设在
client.Call级别，无法区分网络超时与业务超时 - 无内置重试、熔断、链路追踪，得自己包一层
- 服务发现、负载均衡、协议升级（如从 TCP 切到 gRPC）全要手动实现
如果真需要跨语言或云原生支持，直接上 gRPC-Go（基于 Protobuf + HTTP/2）更稳妥。它的 protoc-gen-go 生成代码天然带上下文、拦截器、流控能力。
自定义序列化器要注意什么？
想换 Protobuf 或 MsgPack？net/rpc 允许传入自定义 ClientCodec 和 ServerCodec，但必须严格实现接口：
type ServerCodec interface {
ReadRequestHeader(*Request) error
ReadRequestBody(interface{}) error
WriteResponse(*Response, interface{}) error
Close() error
}
关键点：
-
ReadRequestHeader必须能从字节流中解析出Service.Method字符串和序列号，否则路由失败 - 所有编码器必须保证
WriteResponse和ReadRequestBody字节顺序一致，否则出现“成功写入但读不出”的静默错误 - 不要在编解码器里做阻塞 IO，比如同步调用另一个 HTTP 接口——这会让整个 RPC 连接卡住
实际项目中，90% 的自定义序列化需求，本质是想解决跨语言或性能问题，这时候该考虑的不是修 net/rpc，而是换框架。
