gRPC服务通信模块封装核心是让调用方无感底层细节，需统一处理超时、错误码、重试、连接管理；protoc生成代码须隔离在internal/grpc下，对外仅暴露接口；连接应单例复用并显式配置传输凭证与健康检查；错误须用status.Code解析，超时由封装层注入而非业务侧硬编码。
封装 gRPC 服务通信模块，核心不是写得有多“通用”，而是让调用方不感知底层 transport 细节、不重复处理 context 超时、错误码解析、重试和连接管理——这些该由模块兜底。
protoc 生成代码必须分层隔离，不能直接暴露 .pb.go
直接 import user_pb 或 order_grpc 的包名，会导致业务层强耦合生成代码路径，一旦 proto 文件移动或重构，全量编译失败。
- 定义统一的接口层（如
UserServiceClient），只暴露方法签名，不暴露 grpc.ClientConn 或 stream 类型 - 生成代码仅保留在 internal/grpc 目录下，对外只通过 interface 暴露，例如：
type UserServiceClient interface { GetUser(ctx context.Context, req *UserRequest, opts ...grpc.CallOption) (*UserResponse, error) } -
go_package配置必须带版本或模块前缀（如github.com/yourorg/project/v2/api/user），否则生成的import路径会和你的封装层冲突
客户端连接池必须手动管理，别依赖 grpc.Dial 的默认行为
grpc.Dial 默认不复用连接，每次 new Client 都新建 conn，高频调用下 fd 耗尽、TLS 握手开销飙升。
- 用 sync.Once + 全局变量初始化单例
*grpc.ClientConn，避免重复 Dial - 显式设置
grpc.WithBlock()和grpc.WithTimeout(5*time.Second)，防止阻塞在 DNS 解析或首次连接 - 务必传入
grpc.WithTransportCredentials(insecure.NewCredentials())（开发）或credentials.NewTLS(...)（生产），grpc.WithInsecure()在 Go 1.22+ 已被移除 - 连接健康检查建议用
conn.GetState() == connectivity.Ready，而不是靠业务调用失败后重连
错误处理不能只看 err != nil，必须解析 status.Code
gRPC 错误是封装过的 *status.Status，直接打印 err.Error() 只能看到字符串，无法做策略性降级或重试。
立即学习“go语言免费学习笔记（深入）”；
- 统一用
status.Code(err)判断类型，比如codes.Unavailable触发重试，codes.NotFound直接返回 404 - 避免用
errors.Is(err, xxx)做判断——gRPC 错误不满足 Go error wrapping 约定，必须走status.FromError() - 拦截器里可统一加
grpc.UnaryClientInterceptor，把原始 error 包装成业务错误结构体，例如：if code := status.Code(err); code == codes.DeadlineExceeded { return errors.New("rpc_timeout") }
超时与上下文必须由封装层注入，禁止调用方传 context.Background()
业务代码写 ctx, cancel := context.WithTimeout(context.Background(), 300*time.Millisecond) 是反模式：超时值分散、不可配置、无法统一治理。
- 封装层提供
WithTimeout(time.Duration)选项函数，内部构造带 timeout 的 ctx - 为不同服务设置差异化默认超时（如用户查询 200ms，订单创建 2s），通过配置中心动态加载
- context 不应携带 value（如 traceID），而应由中间件注入；封装层只负责 deadline 和 cancel，不碰
context.WithValue - 流式调用（stream）必须额外处理
context.Done()，否则 Recv() 阻塞导致 goroutine 泄漏
真正难的不是封装出一个“能用”的 client，而是让所有业务方忘记自己在用 gRPC——他们只关心“我要查用户”，而不是“我该怎么 dial、怎么 set timeout、怎么 parse status”。这要求封装层吃掉所有 transport 层细节，同时留出足够扩展点（比如自定义 interceptor、fallback 策略），而不是做成黑盒。
