Go 标准库的 net/rpc 并不内置响应缓存机制；所谓“服务宕机后仍返回结果”，实为客户端未校验 RPC 调用错误，导致程序误将零值（如 0、nil、空结构体）当作有效响应继续使用。
go 标准库的 `net/rpc` 并不内置响应缓存机制；所谓“服务宕机后仍返回结果”，实为客户端未校验 rpc 调用错误，导致程序误将零值（如 `0`、`nil`、空结构体）当作有效响应继续使用。
在 Go 的 net/rpc 中，RPC 调用本身是无状态且无缓存的——客户端每次 Go() 或 Call() 都会尝试通过底层连接发送请求，并等待服务端响应。一旦服务端不可达（如 VM 关机、网络中断、服务进程退出），底层 TCP 连接会逐步超时或断开，后续调用将失败。但关键在于：*Go RPC 不会静默丢弃错误，而是将错误信息明确写入 `rpc.Call.Error字段**。若开发者忽略该字段，仅直接解包Reply，就会无意中使用未初始化的零值（例如int类型的0`），造成“结果仍在返回”的错觉。
这正是你观察到的现象根源：
- Linux 下 TCP 层快速反馈连接重置（RST），Call.Error 立即为非 nil，但你的代码未读取它；
- Windows 下网络栈行为略有差异（如延迟 FIN/ACK 或重传策略不同），可能让部分调用短暂卡在 Done channel 中，而 Reply 始终保持初始零值（var reply int → 0），日志中便持续打印 reply: 0，看似“正常”。
✅ 正确做法：始终检查 Call.Error
修改你的异步调用逻辑，确保在从 divCall.Done 接收后第一件事就是检查错误：
divCall := client.Go("Fibonacci.Calculate", args, &reply, nil)
go func() {
replyCall := <blockquote><p>? 提示：replyCall.Reply 是指向你传入变量的指针（即 &reply），因此 *r 才是真实结果值。直接打印 r 会输出地址，而非数值。</p></blockquote><h3>⚠️ 其他重要注意事项</h3>
- 连接复用 ≠ 响应缓存：rpc.DialHTTP 建立的是持久 HTTP 连接（底层复用 TCP），但这仅优化传输开销，绝不意味着客户端会记忆或重放历史响应。
- 零值陷阱普遍存在：Go 中所有类型都有默认零值（0, "", nil）。RPC 失败时 &reply 指向的内存未被写入，保持原零值——这不是缓存，而是未定义行为下的“巧合”。
-
超时与健壮性建议：
- 使用 client.Go(..., timeout) 或封装带上下文的调用（需自定义 Client 扩展）；
- 对关键业务，添加重试逻辑（带退避）和熔断机制；
- 生产环境推荐迁移到 gRPC（支持内置超时、流控、健康检查）或 REST+JSON，net/rpc 已逐渐被社区视为维护模式。
总结
Go RPC 没有缓存——只有未处理的错误和未察觉的零值。真正的可靠性来自显式错误处理，而非依赖框架“自动兜底”。修复只需一行 if replyCall.Error != nil，却能避免绝大多数生产事故。记住：在分布式系统中，网络永远不可靠，而错误永远存在；忽略它，就等于选择幻觉。
