昨天我在 go 中玩了 RPC 并且有一個我無法理解的行為。我編寫了一個簡單的 RPC 服務器，它在 VM 中運行，監聽連接并為斐波那契計算提供單一方法。本地機器上的 RPC 客戶端每秒向服務器詢問 fibonacci(n)，其中 n 是 (currentSecond*fixedMultiplicator)，因此我可以產生至少稍微不同的負載。因此，在 for 循環中，客戶端將在 60 秒內請求 60 個不同的值，然后重新開始。RPC 撥號在此循環之外，因此連接有些持久。當我殺死服務器時，假設 10 秒后，客戶端將拋出錯誤，因為它無法向現在丟失的服務器發送任何內容。到目前為止，按計劃工作。現在讓我想到的是：當我在 61 秒后終止服務器時，盡管服務器丟失并且無法響應請求，但客戶端仍會為所有請求打印出正確的結果。我什至關閉了服務器的虛擬機，所以服務器 IP 甚至不再在網絡中。雖然有點有趣，但這種行為可能對實際應用程序有害（取決于您正在開發的內容）。有任何想法嗎？// ############// # RPC SERVERerr := rpc.Register(service.Object)// errorcheckrpc.HandleHTTP()l, e := net.Listen("tcp", ":1301")// errorcheckgo http.Serve(l, nil)// ############// # RPC CLIENTclient, err := rpc.DialHTTP("tcp", "192.168.2.111:1301")// errorcheckvar divCall *rpc.Callfor {    <-time.After(time.Duration(1 * time.Second)):    n := time.Now().Second() * 90000000    log.Debug("n=", n)    args := &services.FibonacciArgs{N: n}    var reply int    divCall = client.Go("Fibonacci.Calculate", args, &reply, nil)    go func() {        replyCall := <-divCall.Done        r := replyCall.Reply.(*int)        log.Debug("reply: ", r)    }()}回答在 Linux 和 Windows 上運行代碼后，我注意到了不同的結果。在 Linux 上，回復將始終是適當的零值（在我的情況下為 0）。另一方面，在 Windows 上，回復似乎已被緩存。要走的路是@cnicutar的提示。在 RPC 調用后檢查錯誤值并相應地處理內容。永遠不要盲目相信回復。