gRPC是Go微服务中实现RPC的事实标准，必须通过proto定义+protoc生成代码（--go_out和--go-grpc_out缺一不可）+嵌入UnimplementedXXXServer+显式调用RegisterXXXServer来正确注册服务，否则返回UNIMPLEMENTED错误。
gRPC 是 Go 微服务中实现 RPC 的事实标准，不是“可选项”，而是当前生产环境里最稳妥、性能最优、类型最安全的路径。直接用 net/rpc 或手写 HTTP+JSON 的方案，在服务规模稍大、需要流式通信或跨语言协作时，会迅速暴露维护成本高、错误难定位、性能瓶颈明显等问题。
proto 文件定义必须带 go_package 且路径要匹配模块根目录
这是生成代码后能正常 import 的前提，也是初学者踩坑最多的地方。
-
go_package值不是随意写的路径，它必须与你go mod init时声明的模块名一致（比如github.com/yourname/project），且后面跟的子路径要对应文件实际存放位置 - 例如：你的
user.proto放在proto/user/目录下，那option go_package = "github.com/yourname/project/proto/user";才对；如果写成"./user"，生成的.pb.go文件里 import 路径会错，编译直接报cannot find package - protoc 命令里必须加
--go_opt=paths=source_relative，否则生成的 import 路径可能指向绝对路径或错误相对路径
protoc 命令要同时指定 --go_out 和 --go-grpc_out
只跑 --go_out 只会生成消息结构体，没有服务端接口和客户端 stub；漏掉 --go-grpc_out，RegisterXXXServer 和 NewXXXClient 都不存在。
- 正确命令示例：
protoc --go_out=. --go_opt=paths=source_relative \ --go-grpc_out=. --go-grpc_opt=paths=source_relative \ proto/user/user.proto
- Go 1.21+ 环境下，
protoc-gen-go-grpc必须是 v1.3+ 版本，否则会生成过时的UnimplementedXXXServer接口（已废弃），导致nil实现无法通过编译检查 - 生成的两个文件：
user.pb.go（消息定义）和user_grpc.pb.go（服务桩），缺一不可
服务注册和客户端 Dial 必须用同一套 TLS/凭证配置
本地调试时关 TLS 没问题，但一旦部署到 k8s 或跨节点通信，grpc.Dial 默认不启用 TLS，而服务端若启用了 grpc.Creds，连接会直接失败，错误信息常是 connection refused 或更模糊的 context deadline exceeded。
- 服务端启用 TLS 示例：
creds, _ := credentials.NewServerTLSFromFile("cert.pem", "key.pem") s := grpc.NewServer(grpc.Creds(creds)) - 客户端对应要传入证书：
creds, _ := credentials.NewClientTLSFromCert(nil, "") conn, _ := grpc.Dial("host:50051", grpc.WithTransportCredentials(creds)) - 开发阶段想跳过验证（仅限测试），用
grpc.WithTransportCredentials(insecure.NewCredentials())，但注意这个insecure包在 v1.60+ 已从google.golang.org/grpc移出，需单独导入：google.golang.org/grpc/credentials/insecure
拦截器（interceptor）不是“锦上添花”，而是生产级必需项
没有日志、超时、recover 的 gRPC 服务，在真实流量下等于裸奔。别等线上 panic 了才加 UnaryServerInterceptor。
立即学习“go语言免费学习笔记（深入）”；
- 最简可用组合：
grpc.UnaryInterceptor()+grpc.StreamInterceptor()，分别覆盖一元调用和流式调用 - 超时必须由客户端控制：
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)，服务端不能靠自己 sleep 来模拟——这会导致资源占用不可控 - 日志拦截器要记录
FullMethod和Code，否则排查时根本不知道哪个方法挂了；用zap或slog都行，但别只打一行fmt.Println - go-grpc-middleware 的
recovery.UnaryServerInterceptor能捕获 handler 里的 panic，避免整个 server crash，这个几乎必开
go_package 路径与模块路径的严格一致性，以及拦截器中上下文 timeout 的传递方式——很多问题表面是连接失败或响应慢，根源其实是 proto 路径错导致 client stub 未生效，或 context 没透传导致服务端永远等不到 cancel。 
