net/rpc本质是go同构系统内类型安全的tcp调用，不跨语言、无自动重连/服务发现/默认超时；call失败主因是类型或协议未对齐，如大小写不一致、字段未导出、handler路径错配、url格式错误等。
net/rpc 的通信本质是「Go 语言内部类型安全的 TCP 远程调用」，它**不跨语言、不自动重连、不带服务发现、默认无超时**——想跑通一次调用很容易，但想在分布式环境里稳定用，必须亲手补上这些缺口。
为什么 rpc.Dial("tcp", addr) 连上了却 Call 失败？
常见现象是 unexpected EOF、connection reset 或直接卡住，根本原因往往不是网络不通，而是两端类型或协议没对齐：
- 服务端注册的是
new(Arith)，客户端却用"arith.Multiply"（大小写/包名不一致）→ 报错rpc: can't find service method -
Args或Quotient结构体字段没导出（小写首字母）→gob: type not found或静默零值 - 服务端用了自定义
rpc.Server实例，但 HTTP handler 仍绑定在rpc.DefaultServer→ 客户端 DialHTTP 成功，Call 却 404 或空响应 -
rpc.DialHTTP("tcp", "localhost:1234")少了路径和协议 → 实际解析成 host="localhost:1234"、path="/"，而服务端监听的是/_goRPC_或/rpc
rpc.DialHTTP 和 rpc.Dial 的连接行为差异
两者底层都是 TCP，但封装逻辑完全不同，直接影响错误表现和复用方式：
-
rpc.Dial("tcp", addr)：返回裸 TCP 连接，每次Call复用该连接，**无超时控制、无重试、无 HTTP 状态码**。连接断开后，后续Call会阻塞或报io.EOF -
rpc.DialHTTP("tcp", url)：要求传完整 URL（如"http://localhost:1234/rpc"），走 HTTP POST，服务端必须已注册对应 handler（如http.Handle("/rpc", server.HTTPHandler())）。浏览器 GET 访问会返回405 Method Not Allowed，属正常 - 二者都**不管理连接池**：
*rpc.Client不是线程安全的，多 goroutine 并发Call可能导致响应错乱
gob 编码限制如何影响实际开发？
net/rpc 默认用 encoding/gob，这不是配置项，而是硬编码在 rpc.Server 里的行为。这意味着：
- 客户端和服务端必须用完全相同的 Go 类型定义：相同包路径、相同结构体名、所有字段首字母大写导出
- 不能传
func、channel、unsafe.Pointer，含 interface{} 字段需提前gob.Register - 跨语言调用直接失败——PHP/Python/Java 客户端无法解码 gob 流，不是“配错了”，是协议根本不支持
- 调试困难：Wireshark 抓到的是二进制 gob 流，没法肉眼读；想临时用 curl 测试？不行
生产环境里最常被忽略的三个点
不是“怎么写通”，而是“怎么扛住真实流量”：
-
rpc.Client没有内置超时，Call会无限等待直到连接关闭。必须自己包装：用context.WithTimeout控制 dial 阶段，再用conn.SetDeadline控制单次 call 的读写时限 - 没有连接健康检查机制。长连接空闲后被中间设备（NAT/防火墙）静默断开，下次
Call才暴露问题。得定期发心跳或封装client.Call时捕获io.ErrUnexpectedEOF后重建连接 - 错误透传不透明：服务端
return errors.New("db timeout")能传回来，但若方法签名写成func(*Args, int) error（第二个参数非指针），错误就直接吞掉，客户端收不到任何提示
Call 显式处理超时、重试、连接生命周期和错误语义。标准库只提供骨架，血肉得自己一寸寸填。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
