net/rpc 不能跨语言调用，因其默认使用私有 gob 编码、无标准协议规范、路由和方法名格式不通用；可行方案是 grpc+protobuf 或标准 json-rpc 2.0。
Go 语言本身不提供跨语言 RPC 的“开箱即用”能力，net/rpc 是 Go 原生的、仅限 Go 客户端与 Go 服务端之间通信的机制，无法直接对接 Python、Java 或 Rust 等其他语言。
为什么 net/rpc 不能跨语言调用
net/rpc 默认使用 Go 自有的 gob 编码格式，该格式未公开规范、不向后兼容、且无其他语言官方支持。即使你手动替换编码器（如用 jsonrpc），net/rpc 的请求/响应结构（含方法名拼接规则、错误包装方式）也未标准化，导致其他语言客户端难以可靠解析。
-
gob是 Go 内部序列化格式，Python/Java 没有稳定、兼容的反序列化实现 -
net/rpc的 HTTP handler 路由逻辑硬编码为/_goRPC_，不遵循通用 RPC 协议约定 - 方法名通过
ServiceName.MethodName字符串传递，大小写和命名风格在跨语言时极易不一致
真正可行的跨语言 RPC 方案：gRPC + Protocol Buffers
这是当前最主流、生态最成熟的方案。gRPC 强制使用 protobuf 定义接口和服务契约，生成各语言的客户端/服务端代码，底层基于 HTTP/2，天然支持多语言互操作。
- 定义统一的
.proto文件，例如hello.proto，用protoc工具生成 Go、Python、Java 等对应代码 - Go 服务端用
grpc-go实现，启动grpc.Server监听；其他语言只需用各自语言的 gRPC 库连接同一地址即可 - 注意：必须启用 TLS 或显式配置
grpc.WithTransportCredentials(insecure.NewCredentials())才能在开发环境绕过证书（生产环境不可跳过 TLS） - gRPC 默认压缩 payload，但若需调试，可临时设置
GRPC_VERBOSITY=DEBUG和GRPC_TRACE=all环境变量
轻量替代方案：JSON-RPC over HTTP（适合简单场景）
如果不想引入 gRPC 生态，可用标准 JSON-RPC 2.0 协议，自己封装 HTTP handler。Go 中推荐用 gorilla/rpc 或直接用 net/http + encoding/json 实现，关键是要严格遵循 id、method、params、result、error 字段语义。
- 服务端必须返回符合 JSON-RPC 2.0 规范的响应，例如
{"jsonrpc":"2.0","result":123,"id":1}，任何字段名或结构偏差都会导致其他语言客户端解析失败 - Go 的
json.Unmarshal对字段名大小写敏感，建议在structtag 中显式声明json:"method"等，避免因 Go 命名习惯（首字母大写）导致字段被忽略 - 不要复用
net/rpc/jsonrpc包——它仍是 Go 专用的封装，只是用了 JSON 编码，协议层面仍不兼容标准 JSON-RPC
跨语言 RPC 的核心不是“用 Go 写个服务”，而是“选一个所有目标语言都支持并严格实现的协议”。gRPC 是目前唯一被广泛验证的工业级选择；任何试图魔改 net/rpc 来“兼容其他语言”的做法，最终都会卡在序列化细节或错误传播机制上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
