用途：本技能面向在 Go 中设计与实现生产级 gRPC 服务，适合用 gRPC 设计微服务通信、以 Protobuf 构建高性能内部 API、实现单向或双向流式负载、用 Buf 统一 API 契约，以及为服务间认证配置 mTLS。
主要能力与流程：先确认技术背景（Go 版本、gRPC-Go 版本、项目用 Buf 还是原生 protoc），再确认需求（mTLS、一元或流式负载模式、SLO、消息大小限制）；随后规划 Schema（如 package api.v1 版本化、资源类型与错误映射），进行安全设计（服务间 mTLS），并通过拦截器接入链路追踪、指标与结构化日志；最终在生成代码前始终运行 buf lint 与破坏性变更检查。
示例要点：v1 API 中声明 syntax = "proto3"、package api.v1、option go_package，并定义 service、rpc 与消息类型。
最佳实践：用 buf.yaml 与 buf.gen.yaml 统一工具链与 lint；在包路径中采用语义化版本；内部服务通信强制 mTLS；流式处理中处理 ctx.Done() 防止资源泄漏；把领域错误映射为标准 gRPC 状态码（如 codes.NotFound）。避免向客户端返回原始内部错误字符串或堆栈，避免每次请求新建 grpc.ClientConn，应复用连接。
排错：生成代码与 Schema 不一致时运行 buf generate 并检查 go_package；出现上下文超时检查客户端超时与流式处理是否阻塞；mTLS 握手失败时确认 CA 证书已正确加入双方 x509.CertPool。
限制：不覆盖服务网格流量路由（Istio/Linkerd）、gRPC-Web 与浏览器集成、L7 gRPC 感知负载均衡器（Envoy、NGINX）配置，也不涉及 Buf lint 之外的 Schema 注册表或大规模治理；默认 Go 1.21+ 与 gRPC-Go v1.60+，旧版本 API 可能不同（如 grpc.Dial 与 grpc.NewClient）。纯 REST/HTTP 公开 API 或无版本化能力的遗留 .proto 修改不适用。