Go net/rpc调用无限挂起无报错 代码问题排查与调试建议

你的代码有两个关键问题，其中协议不匹配是导致请求无限挂起的直接原因：

• RPC服务端与客户端协议不匹配：服务端调用了rpc.HandleHTTP()后通过http.Serve启动服务，本质是在端口上提供基于HTTP协议的RPC服务，默认RPC端点路径为/_goRPC；但客户端使用rpc.Dial("tcp", ...)是建立原生TCP连接，直接发送Go RPC私有二进制帧，不符合HTTP协议格式。服务端无法识别非法HTTP请求就不会返回响应，客户端会一直等待服务端回包，最终表现为无限挂起。
• RPC响应赋值逻辑错误：GetMusicProjectById方法中model = &musicProject仅修改了函数内部的指针副本，没有将构造好的响应数据写入调用方传入的指针指向的内存空间，即使请求通了，客户端也拿不到正确的返回值。正确写法应该是解引用指针赋值：*model = musicProject。

两种方案二选一即可：

方案1：保留HTTP RPC模式（改动最小） #

1. 修正服务端响应赋值逻辑：把GetMusicProjectById方法里的model = &musicProject替换为*model = musicProject
2. 修正客户端拨号方式：把rpc.Dial("tcp", "localhost:5002")替换为rpc.DialHTTP("tcp", "localhost:5002")

方案2：使用原生TCP RPC模式 #

1. 同样先修正服务端的响应赋值逻辑
2. 删掉服务端的rpc.HandleHTTP()和http.Serve(l, nil)相关代码，改为在TCP监听循环中直接处理RPC连接，替换代码如下：

log.Println("Starting server port", app.config.server.port)
l, err := net.Listen("tcp", fmt.Sprintf(":%v", app.config.server.port))
if err != nil {
    log.Fatal(err)
}
for {
    conn, err := l.Accept()
    if err != nil {
        log.Printf("accept connection failed: %v", err)
        continue
    }
    go rpc.ServeConn(conn)
}

这种模式下客户端原有rpc.Dial的写法可以保留。

• 给所有RPC操作加超时兜底：不要使用默认无限等待的逻辑，拨号时指定连接超时，调用RPC方法时用异步调用+超时控制避免永久挂死，示例：

// 带超时拨号
dial, err := net.DialTimeout("tcp", "localhost:5002", 3*time.Second)
if err != nil {
    log.Fatal("dial failed:", err)
}
rpcClient := rpc.NewClient(dial)
// 带超时调用
var musicProject MusicProject
call := rpcClient.Go("Application.GetMusicProjectById", projectID, &musicProject, nil)
select {
case resp := <-call.Done:
    if resp.Error != nil {
        log.Println("call failed:", resp.Error)
    }
case <-time.After(5*time.Second):
    log.Println("rpc call timeout")
}

• 分层验证连通性：先用telnet 127.0.0.1 5002确认端口处于监听状态，再验证协议是否匹配，最后验证业务逻辑，不要一开始就全链路联调。
• 服务端增加错误日志：在监听连接、处理请求的位置打错误日志，快速定位是请求没到服务端、还是服务端处理逻辑卡住、还是序列化返回值出错。
• 优先使用结构体作为RPC请求/响应参数：虽然Go的gob编码支持基础类型作为参数，但用结构体传参扩展性更好，也能避免部分序列化兼容问题。

内容的提问来源于stack exchange，提问作者Enrico