gRPC客户端在Go中落地的关键是配置对齐：proto的go_package需匹配生成路径，Dial须用insecure.NewCredentials()禁用TLS，ClientConn全局复用，每次调用配context超时，错误用status.Code区分。
用 Golang 写 gRPC 客户端，不是“写完就能跑”，而是“配对了才通”。最常卡住的地方根本不是代码逻辑，而是 grpc.Dial 的配置和 .proto 生成路径不一致——连不上、报 unknown service、transport: authentication handshake failed，90% 都是这两处没对齐。
proto 文件怎么写才不会被 protoc 报错
很多新手直接复制示例，却忽略 option go_package 和实际文件路径的绑定关系。它不是注释，而是生成代码时 Go 包路径的唯一依据。
-
option go_package = "./pb;pb"表示生成的pb.go文件要放在当前目录的pb/子目录下，且包名是pb - 如果把
service.proto放在api/目录下，又写option go_package = "api"，那必须用protoc --go_out=api/ ...，否则生成的文件会找不到包 - 不写
option go_package也能生成，但后续 import 路径会变成默认的xxx.pb，极易和模块路径冲突
grpc.Dial 怎么配才不报 connection refused 或 handshake failed
本地开发时，默认走 TLS，但服务端没开证书就必然失败。这不是 bug，是设计使然。
- 本地测试必须显式传
grpc.WithTransportCredentials(insecure.NewCredentials())，否则永远卡在 handshake -
grpc.WithBlock()只应在调试时加，它会让Dial同步阻塞直到连接建立；生产环境应去掉，靠后续健康检查或重试机制兜底 - 地址写
"localhost:50051"没问题，但别写"127.0.0.1:50051"然后服务端监听localhost——某些系统 DNS 解析行为会导致连接失败
客户端调用时 context 不设超时等于埋雷
不带超时的 context.Background() 调用，一旦服务端 hang 住或网络抖动，goroutine 就永久卡死，资源无法释放。
立即学习“go语言免费学习笔记（深入）”；
- 每次 RPC 调用前必须用
context.WithTimeout(ctx, 3*time.Second)控制最大耗时 - 不要复用同一个
context.WithCancel实例跨多次调用——cancel 后 context 就失效，后续调用直接返回context.Canceled - 错误判断别只看
err != nil，要用status.Code(err)区分是服务端业务错误（如codes.NotFound）还是连接类错误（如codes.Unavailable）
*grpc.ClientConn 必须全局复用，不能每次调用都 Dial
Go 的 *grpc.ClientConn 是线程安全、可复用的长连接句柄。反复 Dial 不仅慢，还会快速触发 too many open files。
- 在
init()或应用启动时初始化一次，赋值给包级变量或注入到结构体中 - 不要在函数里
defer conn.Close()——这会提前关掉整个连接池 - 连接生命周期应由应用管理，比如在
main()结束前统一conn.Close()
真正难的不是写 c.SayHello() 这一行，而是确保 protoc 生成的包路径能被 import 到、grpc.Dial 的凭证匹配服务端模式、每个 ctx 都有合理 deadline、ClientConn 不被误销毁——这些点串起来，才是 gRPC 在 Go 里落地的最小完整链路。
