gRPC 是跨语言 RPC 的事实标准，因其基于 HTTP/2 和 Protocol Buffers，具备服务发现、流控、超时等生产级能力，且所有主流语言均有成熟实现；关键在于确保 proto3 语法显式声明并跨语言同步，首行必须为 syntax = "proto3";，避免因版本错配导致字段丢失或校验失败。
gRPC 是跨语言 RPC 的事实标准，不是可选项
Go 服务要和 Java/Python/Node.js 等互通，net/rpc 和 jsonrpc 都撑不住——前者用 gob 编码，后者虽用 JSON 但缺乏服务发现、流控、超时等生产级能力，且 HTTP/1.1 模型对长连接和并发不友好。真正能落地的只有 gRPC，它基于 HTTP/2 + Protocol Buffers，所有主流语言都有成熟实现。
关键不是“能不能”，而是“怎么避免踩坑”。跨语言失败的绝大多数情况，不是代码写错，而是协议层不一致。
proto3 语法必须显式声明，且所有语言保持同步
常见错误：rpc error: code = InvalidArgument desc = field xxx is required but not set 或 Go 客户端收不到 Java 传来的 string 字段——本质是 proto 版本错配。
-
.proto文件顶部第一行必须是syntax = "proto3";，不能省略，也不能写成proto2 - Java 旧版
protobuf-java（option java_multiple_files = true; - Python 客户端若用
protobuf--experimental_allow_proto3_optional（如用到optional字段） - 枚举第一个值必须为
UNKNOWN = 0;，否则 Go 默认填充 0，Java/Python 可能因未初始化而抛IllegalArgumentException
HTTP/2 端口暴露方式必须干净，别塞进 http.ServeMux
Go 服务端如果把 grpc.Server 注册进 http.ServeMux，或者用 http.ListenAndServe 启动混合 handler，就会导致 Java/Python 客户端连接后立刻断开，报错 transport is closing 或直接 connection refused。
立即学习“go语言免费学习笔记（深入）”；
正确做法只有一条路径：
- 用
net.Listen("tcp", ":50051")直接监听 TCP 端口 - 传给
grpc.NewServer()，再调用server.Serve(lis) - 绝对不要用
http.Handle("/xxx", grpcHandler)或类似包装 - 验证是否通：用
grpcurl -plaintext localhost:50051 list能列出服务名，就说明 HTTP/2 层通了
客户端必须显式声明非 TLS 模式
Java 和 Python 客户端默认尝试 TLS 握手，而 Go 服务端没配证书时会静默拒绝连接，现象是超时或 UNAVAILABLE 错误，日志里却看不到有效线索。
- Java 客户端必须加
.usePlaintext()：ManagedChannelBuilder.forAddress("host", 50051).usePlaintext() - Python 客户端必须用
grpc.insecure_channel()：channel = grpc.insecure_channel('localhost:50051') - Go 客户端连其他语言服务时同理：用
grpc.WithTransportCredentials(insecure.NewCredentials()) - 别信“开发环境可以省略”——一旦中间有代理、Nginx 或 Istio，
usePlaintext()就变成必填项
跨语言 RPC 最容易被忽略的，不是代码逻辑，而是每个环节的协议契约：proto 版本、HTTP/2 行为、TLS 显式开关、枚举零值定义。少一个，调用就静默失败。
