Go中用Protobuf实现RPC需严格遵循三要点：1.正确安装protoc-gen-go和protoc-gen-go-grpc插件并验证路径；2..proto中go_package必须为完整模块路径且与go.mod一致，字段名用下划线风格；3.服务端监听地址须用":8080"或"0.0.0.0:8080"而非"localhost:8080"。
直接上结论：go 里用 protobuf 做 rpc，不是“装完工具就能跑”，90% 的失败卡在 protoc 插件版本错、go_package 路径不匹配、监听地址写成 "localhost:8080" 这三处。
protoc-gen-go 和 protoc-gen-go-grpc 必须装对版本
常见现象是生成的代码里没有 RegisterXXXServer 函数，或者方法签名和 .proto 定义对不上——这基本等于插件没装对或装混了。
必须执行这两条命令（注意不是 grpc-go 包）：
go install google.golang.org/protobuf/cmd/protoc-gen-go@latest go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@latest
验证方式：检查 $GOPATH/bin 下是否存在 protoc-gen-go 和 protoc-gen-go-grpc 两个可执行文件；如果 protoc --version 输出是 libprotoc 3.21.12 或更高，但生成失败，大概率是插件路径没进 PATH。
proto 文件里 go_package 和字段命名规则不能松动
错误写法：option go_package = "pb"; 或 userEmail = 1; —— 前者导致生成代码进 main 包，后者让 JSON 映射和反射行为不一致。
立即学习“go语言免费学习笔记（深入）”；
正确写法要同时满足：
-
option go_package必须是完整模块路径，比如option go_package = "example.com/pb";，且和go.mod的 module 名一致 - 字段名用下划线风格（
user_email = 1;），Go 结构体字段会自动转成小驼峰（UserEmail） -
syntax = "proto3";后面不能跟空行或注释，否则protoc直接报错退出
服务端监听地址写 "localhost:8080" 就等于只给自己用
现象是本地 curl 或客户端连不上，报 connection refused —— 这不是防火墙或端口占用问题，而是 Go 服务根本没对外暴露。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
net.Listen("tcp", "localhost:8080") 绑定的是回环地址，容器、宿主机其他进程、Docker 网络都访问不到。
必须改成：
lis, err := net.Listen("tcp", ":8080")
// 或显式写全
lis, err := net.Listen("tcp", "0.0.0.0:8080")
另外注意：server.Serve(lis) 是阻塞调用，别在它前面加日志就以为“服务启动成功”——那句日志之后代码就卡死了，后续逻辑不会执行。
客户端 Dial 频繁新建连接会导致 context deadline exceeded
这不是服务端慢，是客户端自己搞崩了。每次请求都 grpc.Dial + Close，会触发连接风暴，gRPC 底层来不及复用连接，超时就必然发生。
正确做法：
- 全局复用一个
*grpc.ClientConn，比如存在包变量或结构体字段里 - 调用前用带超时的上下文：
ctx, cancel := context.WithTimeout(ctx, 5*time.Second) - 如果用了 TLS，客户端必须传
credentials.NewTLS()，否则默认走明文，直接报transport: authentication handshake failed
最易被忽略的一点：gRPC 默认不支持 HTTP/1.1，也不接受非 TLS 的明文连接（除非显式配置 insecure）。开发阶段为了省事开 grpc.WithTransportCredentials(insecure.NewCredentials()) 可以，但上线前必须切回 TLS，否则连接会静默失败。
