Go语言recover处理RPC调用panic完整教程-Golang-PHP中文网

recover必须在服务端RPC handler的defer中注册，客户端无法捕获服务端panic；需用recoverRPCHandler包装HTTP handler，配合runtime.Stack记录完整堆栈，并在RPC方法内做参数校验与资源清理。

go语言recover处理rpc调用panic完整教程

recover必须在RPC handler的defer里注册，不能靠客户端捕获

Go标准库net/rpc的HTTP模式下，每个RPC请求由独立的HTTP handler处理，而panic只会在该handler goroutine内传播。客户端调用client.Call()时，无论服务端panic与否，返回的都是error（比如rpc: server error: runtime error: ...），但这个error是服务端序列化后的字符串，无法被recover捕获——因为recover只对当前goroutine生效，且必须在panic发生后、goroutine退出前执行。

常见错误是试图在客户端写defer recover()来“兜住”服务端panic，这完全无效。真正要拦住panic，只能在服务端handler入口处加defer + recover。

服务端panic发生时，HTTP handler goroutine正在执行，此时只有它自己的defer链能介入
客户端goroutine和服务端goroutine物理隔离，不存在跨goroutine recover机制
即使使用gRPC等框架，服务端panic也必须在服务端方法入口或中间件中recover，而非stub层

HTTP RPC服务端统一recover中间件写法

标准库net/rpc不提供中间件机制，需手动包装http.Serve的handler。核心是替换http.Serve使用的Handler，在每次RPC请求进入时插入recover逻辑。

示例代码（精简关键部分）：

func recoverRPCHandler(h http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if p := recover(); p != nil {
                // 记录完整堆栈，不只是p
                buf := make([]byte, 4096)
                n := runtime.Stack(buf, false)
                log.Printf("RPC panic recovered: %v\n%s", p, buf[:n])
                // 返回标准HTTP 500，让客户端收到可解析的error
                http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            }
        }()
        h.ServeHTTP(w, r)
    })
}
<p>// 启动时包装
rpc.HandleHTTP()
http.Handle("/rpc", recoverRPCHandler(http.DefaultServeMux))
l, _ := net.Listen("tcp", ":1234")
http.Serve(l, nil)
</p>

必须在rpc.HandleHTTP()之后、http.Serve()之前替换handler，否则无效
runtime.Stack(buf, false)比fmt.Sprintf("%+v", p)更可靠，能拿到调用链
不要只打印p，否则丢失行号和函数名，线上排查基本不可用

RPC方法内部仍可能漏掉panic：nil指针、map写入未初始化等

即使加了顶层recover，业务RPC方法里仍可能触发panic，比如：args.User.Name中args.User为nil、向未make的map写入、数组越界等。这些panic发生在RPC方法执行过程中，会被上面的recoverRPCHandler捕获，但问题在于：recover后handler已返回HTTP 500，客户端无法区分是服务崩溃还是业务参数错。

3-Tier Auto-Backup Daily Snapshots, Drive Mirror & Emergency Recovery

三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。

下载

建议在每个RPC方法开头做基础校验：if args == nil { return errors.New("args is nil") }
对所有指针字段做非空检查，尤其来自客户端输入的结构体嵌套字段
避免在RPC方法里直接操作全局变量或共享map/slice，除非加锁且确保已初始化
测试阶段用go test -race跑并发RPC调用，暴露数据竞争引发的panic

recover后资源清理常被忽略：连接、文件句柄、goroutine泄漏

recover只是让goroutine不退出，但panic发生前已申请的资源不会自动释放。比如RPC方法里打开了数据库连接、创建了子goroutine、持有了文件句柄，recover后若不显式清理，会导致连接池耗尽、fd泄漏、goroutine堆积。

正确做法是在recover前注册清理逻辑，利用defer的LIFO顺序：

func (t *Arith) Multiply(args *Args, reply *int) error {
    db, err := getDBConn()
    if err != nil {
        return err
    }
    defer db.Close() // 这个defer在recover前注册，panic时仍会执行
<pre class="brush:php;toolbar:false;">// 可能panic的业务逻辑
*reply = args.A * args.B // 如果args为nil，这里panic
return nil

}

所有defer语句必须在panic发生前执行到，才能保证recover后它们被调用
不要把清理逻辑写在recover块里，因为recover块本身是panic之后才运行的，此时资源可能已损坏
特别注意goroutine泄漏：如果RPC方法启动了子goroutine并传入了args或reply指针，recover后这些goroutine可能还在运行并访问已失效内存

真实生产环境里最棘手的不是recover写不写，而是recover之后——堆栈没打全、指标没上报、资源没释放、错误分类没做。这些细节不补上，recover就只是把崩溃从“立刻死”变成“缓慢窒息”。