net/rpc卡住因服务端未调用http.Serve或客户端未用rpc.DialHTTP；gob不跨语言因绑定Go类型系统；TCP裸连需用rpc.ServeConn；context无法穿透因方法签名固定。
为什么直接用 net/rpc 会卡在连接建立后没响应
Go 标准库的 net/rpc 默认使用 HTTP 作为传输协议，但它的服务端必须显式调用 http.Serve 启动监听，且要求客户端发起的是标准 HTTP POST 请求（带特定 header 和 body 编码）。很多人照着文档写了个 rpc.Register 就以为能通，结果 client.Call 一直阻塞或返回 dial tcp: operation was canceled —— 实际是服务端根本没真正“跑起来”，或者客户端没走对协议路径。
实操建议：
- 服务端必须用
http.ListenAndServe或http.Serve启动，不能只注册服务就结束 - 客户端必须用
rpc.DialHTTP（而非rpc.Dial），否则底层不会构造符合 RPC 协议的 HTTP 请求 - 注册的服务结构体方法必须满足：首字母大写、参数和返回值都是导出类型、最后一个参数是指针类型（用于输出）
gob 编解码在跨语言场景下为什么完全不可用
net/rpc 默认用 gob 序列化，它深度绑定 Go 运行时类型系统：字段名、包路径、结构体 tag 都参与编码。一旦换语言（比如 Python 客户端）、甚至只是 Go 版本升级导致 gob 格式微调，就会出现 unexpected EOF 或 invalid type 错误。
实操建议：
- 如果只做内部 Go-to-Go 调用，
gob没问题，性能好、零配置 - 只要存在跨语言、长期兼容、或需要调试抓包的需求，立刻切换到
jsonrpc：用rpc.NewServer().RegisterCodec+jsonrpc.NewCodec（需golang.org/x/net/rpc/jsonrpc） - 注意
jsonrpc仍复用 HTTP transport，所以服务端依然要走http.Serve，但请求 body 是 JSON 格式，可用curl直接测试
如何让服务端支持非 HTTP 的裸 TCP 连接
标准 net/rpc 的 rpc.ServeConn 可以接管任意 net.Conn，包括 TCP、Unix socket 甚至内存管道。这时候就不走 HTTP 层，而是直接在 TCP 流上跑 gob 编码——更轻量，也避免了 HTTP 的 header 解析开销。
实操建议：
- 服务端启动监听后，对每个
accept到的conn，单独起 goroutine 执行rpc.ServeConn(conn) - 客户端改用
rpc.Dial("tcp", "127.0.0.1:8080")，不用DialHTTP - 注意：TCP 模式下没有内置超时或重连逻辑，
conn断开后服务端的ServeConn会自然退出，但客户端需自己处理io.EOF并重建连接 - 如果想加心跳或连接复用，得自己包装
net.Conn，标准库不提供
为什么 context.Context 无法穿透 net/rpc 调用链
net/rpc 的方法签名固定为 func(*Args, *Reply) error，没有地方塞 context.Context。这意味着你无法在服务端方法里感知客户端是否已取消、也无法设置 deadline。所有超时都得靠客户端 Call 时传入的 time.Duration，服务端对此无感知。
实操建议：
- 若需上下文传递（如 trace ID、鉴权信息、截止时间），必须把 context 数据显式塞进
*Args结构体中，服务端再手动解析 - 不要试图给
rpc.Server方法加 context 参数——编译不过，也不符合 RPC 协议设计 - 真要强依赖 context 生态（如 opentelemetry），建议直接上 gRPC，而不是硬改标准库 RPC
最易被忽略的一点：服务端注册方法时，如果结构体字段没导出（小写开头），gob 编码会静默跳过，客户端收到的 Reply 里对应字段永远是零值，且不报错。调试时得先确认所有参与通信的字段名首字母大写。
