go net/rpc 错误返回机制不透明，因gob不支持Error接口序列化，导致客户端无法获取真实错误信息；应改用jsonrpc并定义结构化错误类型RPCError，将错误作为响应体字段显式传递，同时全局拦截panic并转换为RPCError。
Go net/rpc 的错误返回机制不透明，error 会被序列化丢弃
Go 标准库 net/rpc 默认使用 gob 编码，而 error 接口本身无法被直接序列化。服务端返回的 error 在客户端收到时往往变成 nil 或泛化为 "rpc: service/method returned error: …" 这类无意义字符串，真实错误信息丢失。
根本原因：gob 不支持接口类型（如 error）的跨进程传输，除非你显式实现 gob.GobEncoder/GobDecoder —— 但标准 errors.New 和 fmt.Errorf 返回的错误都不满足。
- 服务端写
return nil, fmt.Errorf("user not found: %d", id)，客户端拿到的err可能是nil或一个空错误 - 即使非空，也常是
*net/rpc.ServerError，其Error()方法只返回固定前缀 + 字符串，原始堆栈、类型、字段全丢 - 自定义错误结构体若未导出字段或未实现 gob 编解码，同样无法传递
用 jsonrpc 替代 gob 并封装结构化错误响应
最稳妥的方案是放弃 net/rpc 默认的 gob，改用 net/rpc/jsonrpc，并约定统一的错误响应格式。JSON 能自然序列化 map、Struct，便于携带错误码、消息、详情字段。
关键不是换编码，而是把错误「作为返回值的一部分」显式设计，而非依赖 RPC 框架的 error 参数。
立即学习“go语言免费学习笔记（深入）”；
- 服务端方法签名改为返回
(Result, *RPCError)结构体，其中RPCError是你定义的可序列化错误类型 - 客户端不依赖
call.Error，而是检查返回值中的*RPCError字段 - 避免在
jsonrpc中混用gob注册逻辑（比如误调rpc.register后又用jsonrpc.ServeConn）
type RPCError struct { Code int `json:"code"` Message string `json:"message"` Details string `json:"details,omitempty"` } type GetUserResponse struct { User *User `json:"user"` Error *RPCError `json:"error"` } func (s *UserService) GetUser(r *GetUserRequest, resp *GetUserResponse) error { u, err := s.db.FindUser(r.ID) if err != nil { *resp = GetUserResponse{ Error: &RPCError{ Code: 404, Message: "user not found", Details: err.Error(), }, } return nil // 注意：这里 return nil，错误走 resp.Error } resp.User = u return nil } rpc.Client.Call 的 err 只反映传输/协议层失败，不是业务错误
很多人误以为 client.Call(..., &reply, &err) 中的 err 是服务端抛出的业务错误，其实它只表示：连接断开、超时、编码失败、服务端 panic、方法不存在等底层问题。只要请求发出去且收到响应，这个 err 就是 nil —— 即使服务端逻辑返回了 fmt.Errorf("invalid input")。
-
err != nil→ 网络失败、服务宕机、序列化异常、服务端没启动监听 -
err == nil→ 请求已送达且响应已解析，但业务是否成功需检查 reply 内容 - 服务端 panic 会导致
err是"rpc: call failed: EOF"或类似，不是 panic 信息本身
不要在服务端 panic，要用 recover 统一转成结构化错误
RPC 服务端方法里一旦 panic，整个连接可能中断，jsonrpc 会返回模糊的 "EOF"，gob 则直接崩溃。必须主动拦截 panic，并转换为客户端可识别的 RPCError。
推荐在 handler 外层加 recover，而不是每个方法都写 defer —— 可以用中间件模式包装注册的服务对象。
- 不要写
if err != nil { panic(err) } - 不要依赖
log.Fatal或 os.Exit 杀掉整个 server - recover 后应记录日志（含堆栈），再构造
RPCError{Code: 500, Message: "internal error"}返回
func (s *UserService) safeCall(fn func() error) error { defer func() { if r := recover(); r != nil { log.Printf("panic in RPC method: %+v", r) // 此处可触发告警、上报 Sentry 等 } }() return fn() } func (s *UserService) GetUser(r *GetUserRequest, resp *GetUserResponse) error { return s.safeCall(func() error { u, err := s.db.FindUser(r.ID) if err != nil { *resp = GetUserResponse{ Error: &RPCError{Code: 404, Message: "user not found"}, } return nil } resp.User = u return nil }) }RPC 错误处理的核心不是“怎么捕获 err”，而是“怎么让错误可读、可分类、可追踪”。结构化响应体 + 显式错误字段 + 全链路 panic 拦截，这三者缺一不可。否则你永远在日志里 grep “rpc:” 然后猜发生了什么。