net/rpc 要求方法签名严格合规：首字母大写的导出方法、指针接收者、Args 和 Reply 参数、仅 error 返回值；需显式调用 rpc.HandleHTTP() 暴露 HTTP 接口；rpc.DialHTTP 不支持 context 超时，易阻塞。
net/rpc 是 Go 标准库中一个轻量级、基于反射的远程过程调用框架，它不依赖外部协议（如 gRPC 的 HTTP/2 或 Protocol Buffers），而是用 gob 编码 + TCP 或 HTTP 传输，目标是让“调用远程方法像调用本地函数一样简单”——但这个“简单”有严格前提，一旦签名或注册出错，就会静默失败或报错难定位。
RPC 方法签名必须满足这四个硬性条件
Go 的 net/rpc 在服务端注册时会通过反射检查方法签名，不合规的方法会被直接忽略（不会报错），导致客户端调用时返回 method not found。常见合规写法：
- 方法名首字母大写（必须导出）
- 接收者是指针类型（
func (t *Arith) Multiply(...)，不是func (t Arith) Multiply(...)） - 第一个参数是请求结构体指针（
*Args），且该结构体字段必须可导出（首字母大写） - 第二个参数是响应结构体指针（
*Reply），返回值只能是error
反例：func (t Arith) Multiply(args Args, reply int) error 会触发 rpc: method has wrong number of ins 或 rpc: reply type is not a pointer —— 这类错误往往在客户端才暴露，服务端启动时毫无提示。
rpc.HandleHTTP() 不是可选项，而是 HTTP RPC 的开关
很多初学者以为只要 rpc.Register() 就能走 HTTP，结果客户端用 rpc.DialHTTP 一连就报 unexpected HTTP response: 404 Not Found。根本原因是：注册服务 ≠ 暴露 HTTP 接口。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
rpc.Register()只把方法注册进rpc.DefaultServer的内部服务表 -
rpc.HandleHTTP()才会把rpc.DefaultServer的 HTTP handler 注册到http.DefaultServeMux，默认挂载路径为/rpc和/debug/rpc - 如果用了自定义
http.ServeMux（比如mux := http.NewServeMux()），不能直接调rpc.HandleHTTP()，而要手动绑定：http.Handle("/rpc", rpc.DefaultServer)
漏掉 rpc.HandleHTTP()，等于只建了工厂没开大门，客户端自然 404。
客户端 rpc.DialHTTP 的底层行为你得心里有数
rpc.DialHTTP 看似简单，实则暗含两层连接逻辑：
- 先用
net.Dial建立 TCP 连接（协议名传"tcp"，地址传"127.0.0.1:8080"） - 连接建立后，立刻向
http://127.0.0.1:8080/rpc发起 POST 请求，携带 gob 编码的调用数据 - 它**不支持 context 超时**，所以若网络卡住或服务未监听，会无限等待 TCP 握手完成 —— 必须自己用
net.DialTimeout封装，或改用rpc.DialHTTPPath配合自定义 dialer
这也是为什么服务端监听 "localhost:8080"，而客户端连 "127.0.0.1:8080" 有时会失败：IPv6/IPv4 解析差异可能导致 net.Dial 卡死，而非快速报错。
真正容易被忽略的，不是“怎么写”，而是“怎么不写错”：方法签名的大小写、指针、导出规则，服务注册与 HTTP 暴露的分离设计，以及客户端 dial 的阻塞本质——这些细节不显眼，却决定 RPC 是跑通还是静默崩坏。
