Go服务端默认要求TLS，需显式配置credentials.NewInsecure()才能对接Python/Java的明文gRPC客户端；监听必须用net.Listen("tcp", ":port")并传给server.Serve()，不可混用HTTP/1.1。
Go服务端默认拒绝明文gRPC调用，Python/Java客户端连不上不是代码写错了，大概率是TLS配置没关或HTTP/2监听没配对。
Go服务端必须显式禁用TLS才能对接非浏览器客户端
gRPC-go的grpc.NewServer()默认要求TLS，但Python的grpc.insecure_channel()和Java的ManagedChannelBuilder.forPlaintext()走的是明文HTTP/2。两边不匹配就会卡在connection refused或日志里只报transport is closing，没有更具体的错误提示。
- 开发阶段加
grpc.Creds(credentials.NewInsecure())启动服务端，别漏掉import "google.golang.org/grpc/credentials" - 对应Python客户端用
grpc.insecure_channel("localhost:50051")，Java用.usePlaintext() - 生产环境切回TLS时，Go侧用
credentials.NewTLS(&tls.Config{...})，Python/Java必须加载PEM格式根证书，Java不能直接读JKS
proto文件必须统一管理且生成命令要严格对齐
不同语言对.proto解析稍有差异，比如Go用optional字段而Python没重生成，或Java用了旧版protoc插件，运行时就抛invalid message或unknown field——这类错误不会在编译期暴露，只在首次调用时炸。
- 所有
.proto文件放独立Git仓库，用子模块或私有包引入，禁止各语言项目本地拷贝 - Go侧生成命令固定为：
protoc --go_out=. --go-grpc_out=. -I. your_service.proto（Go 1.21+） - Python用
grpcio-tools==1.60.*，Java用protobuf-maven-plugin 3.24.x，protoc版本统一为24.x -
.proto里禁用map默认值、oneof隐式赋值等语法糖，只保留syntax = "proto3";和基础字段定义
数值和bytes字段在跨语言间容易类型错位
Go的int32在Python里是int，Java却是可空的Integer；Go返回0时Java可能当成“未设置”；更隐蔽的是bytes字段——Go用[]byte，Python是bytes，Java是ByteString，序列化字节流稍有偏差就触发INVALID_ARGUMENT。
立即学习“go语言免费学习笔记（深入）”；
- 数值字段优先用
sint32/sint64替代int32/int64，避免符号扩展歧义 -
bytes字段传二进制内容前，在Go侧用proto.Marshal确保编码一致，Python/Java侧用对应语言的ParseFromString或parseFrom反序列化 - 调试时用
protoc --decode_raw < payload.bin直接看原始字节，比打日志更准
Go服务监听必须绑定TCP listener，不能混用HTTP/1.1接口
常见误操作是把grpc.Server塞进http.ListenAndServe，或者监听地址写成http://localhost:50051——gRPC依赖原生HTTP/2，需要net.Listen("tcp", ":50051")后直接传给server.Serve(lis)。
- 检查监听是否生效：用
curl -v http://localhost:50051应该返回HTTP/2 404或直接拒绝，而不是HTTP/1.1 200 - 若需共用端口（如gRPC+REST），必须用
grpc-gateway做反向代理，不能让gRPC server自己处理HTTP/1.1请求 - 容器部署时确认
EXPOSE 50051且K8s Service的port和targetPort都设为50051，别被Ingress默认的HTTP/1.1转发劫持
最常被忽略的是proto版本与生成工具链的隐式耦合——哪怕只是升级了protoc到25.x，Go侧没同步升级protoc-gen-go-grpc，就可能生成不兼容的stub，导致流式调用中途断连，这种问题查日志根本看不出端倪。
