答案：Golang RPC异常捕获需通过error返回值处理网络、调用、业务及panic错误，客户端检查error并分类应对，服务端用defer+recover防止崩溃并返回error。
在使用 Golang 进行 RPC 调用时，异常捕获的关键在于正确处理返回的 error 以及服务端可能抛出的自定义错误。Golang 的 net/rpc 包本身不直接支持 panic 恢复或异常传递，因此需要通过 error 返回值和合理的结构设计来实现异常捕获。
理解 RPC 错误的来源
RPC 调用中的“异常”通常表现为以下几种情况：
- 网络连接失败（如服务未启动、超时）
- 方法调用失败（如参数不匹配、方法不存在）
- 业务逻辑错误（服务端主动返回 error）
- 服务端 panic 导致连接中断
这些都需要在客户端通过判断 error 是否为 nil 来捕获。
客户端进行异常捕获
在客户端调用 RPC 方法后，必须检查返回的 error：
立即学习“go语言免费学习笔记（深入）”；
client, err := rpc.Dial("tcp", "127.0.0.1:8080")
if err != nil {
log.Fatal("连接失败:", err)
}
var reply string
err = client.Call("Service.Method", "args", &reply)
if err != nil {
log.Printf("RPC 调用失败: %v", err)
// 在这里进行异常处理，比如重试、降级、上报等
}
常见错误类型包括 rpc.ErrShutdown（连接已关闭）、网络超时等，可以根据 error 内容做进一步分类处理。
服务端主动返回错误
服务端方法可以通过返回 error 来通知客户端失败：
func (s *Service) Method(args string, reply *string) error {
if args == "" {
return fmt.Errorf("参数不能为空")
}
*reply = "成功"
return nil
}
这个 error 会自动传递到客户端，客户端可通过 error 值判断具体错误信息。
防止服务端 panic 导致崩溃
如果服务端处理过程中发生 panic，会导致整个 RPC 服务中断。建议在关键方法中使用 defer + recover 进行保护：
func (s *Service) Method(args string, reply *string) error {
defer func() {
if r := recover(); r != nil {
log.Printf("recover from: %v", r)
}
}()
// 业务逻辑
*reply = "response"
return nil
}
虽然 recover 能防止程序崩溃，但无法通过 RPC 返回给客户端，因此建议在 recover 后仍返回一个明确的 error。
基本上就这些。关键是始终检查 error，服务端避免 panic，客户端做好容错。Golang 的 RPC 异常处理依赖显式错误传递，而不是抛出异常。
