昨天我在 go 中玩了 RPC 并且有一個(gè)我無法理解的行為。我編寫了一個(gè)簡(jiǎn)單的 RPC 服務(wù)器，它在 VM 中運(yùn)行，監(jiān)聽連接并為斐波那契計(jì)算提供單一方法。本地機(jī)器上的 RPC 客戶端每秒向服務(wù)器詢問 fibonacci(n)，其中 n 是 (currentSecond*fixedMultiplicator)，因此我可以產(chǎn)生至少稍微不同的負(fù)載。因此，在 for 循環(huán)中，客戶端將在 60 秒內(nèi)請(qǐng)求 60 個(gè)不同的值，然后重新開始。RPC 撥號(hào)在此循環(huán)之外，因此連接有些持久。當(dāng)我殺死服務(wù)器時(shí)，假設(shè) 10 秒后，客戶端將拋出錯(cuò)誤，因?yàn)樗鼰o法向現(xiàn)在丟失的服務(wù)器發(fā)送任何內(nèi)容。到目前為止，按計(jì)劃工作?，F(xiàn)在讓我想到的是：當(dāng)我在 61 秒后終止服務(wù)器時(shí)，盡管服務(wù)器丟失并且無法響應(yīng)請(qǐng)求，但客戶端仍會(huì)為所有請(qǐng)求打印出正確的結(jié)果。我什至關(guān)閉了服務(wù)器的虛擬機(jī)，所以服務(wù)器 IP 甚至不再在網(wǎng)絡(luò)中。雖然有點(diǎn)有趣，但這種行為可能對(duì)實(shí)際應(yīng)用程序有害（取決于您正在開發(fā)的內(nèi)容）。有任何想法嗎？// ############// # 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 上運(yùn)行代碼后，我注意到了不同的結(jié)果。在 Linux 上，回復(fù)將始終是適當(dāng)?shù)牧阒担ㄔ谖业那闆r下為 0）。另一方面，在 Windows 上，回復(fù)似乎已被緩存。要走的路是@cnicutar的提示。在 RPC 調(diào)用后檢查錯(cuò)誤值并相應(yīng)地處理內(nèi)容。永遠(yuǎn)不要盲目相信回復(fù)。