直接用 grpc-go 可行但需避开三大陷阱：proto定义不匹配、连接未复用、context超时失控；必须严格对齐字段名与json_name、全局复用ClientConn、由客户端context控制超时并主动检查流错误。
直接用 grpc-go 是可行的，但必须避开三个常见陷阱：proto定义不匹配、连接未复用、context超时失控。否则服务一压就崩，日志里满屏 context deadline exceeded 或 transport: error sending ping。
proto3定义必须严格对齐Go结构体字段名和json_name
很多团队改完 .proto 文件后只跑一次 protoc，却忽略生成代码与实际业务结构体的映射一致性。比如字段 user_id = 1 在 Go 中对应结构体字段 UserID，但若没显式加 [json_name = "user_id"]，HTTP/JSON网关或前端调试工具就会解析失败。
- 所有 message 字段名统一用
snake_case，并在 proto 中显式声明json_name（如string user_name = 1 [json_name = "user_name"];） - 避免手动修改
*_pb.go文件——下次生成会覆盖，且破坏go generate流程 -
repeated字段生成为切片，但空切片[]string{}和 nil 切片序列化行为不同：gRPC 默认不发送 nil，建议初始化为空切片 - service 方法签名必须完整，
rpc GetUser(UserRequest) returns (UserResponse);中returns不可省略
客户端连接必须全局复用，不能每次调用都 Dial
频繁调用 grpc.Dial 会导致大量 TCP 握手、TLS 协商和 DNS 查询，吞吐量断崖式下跌。实测在 QPS > 200 场景下，每请求新建连接会使 P99 延迟从 12ms 拉高到 350ms+。
- 用单例模式管理
*grpc.ClientConn，在init()或服务启动时完成初始化 - 生产环境禁用
WithBlock()，改用WithTimeout()+ 后续健康检查（如conn.GetState() == connectivity.Ready） - 超时必须由客户端 context 控制：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，服务端不感知该 timeout - 务必在进程退出前调用
conn.Close()，否则 goroutine 和连接资源泄漏
流式响应必须主动检查 ctx.Err() 并判断 Send() 错误
服务端用 stream.Send() 推送数据时，如果客户端消费慢或网络抖动，gRPC 内部缓冲区会堆积，最终触发 context.DeadlineExceeded 或 transport: failed to write a frame，但错误不会自动中断循环。
立即学习“go语言免费学习笔记（深入）”；
- 每次
stream.Send()后必须判断错误：if err := stream.Send(msg); err != nil { return err } - 循环内持续检查
stream.Context().Err() != nil，一收到 cancel 或 deadline 立即 break - 不要无节制地批量
Send()；如需背压，可用stream.SetHeader()传元数据，或改用双向流让客户端通过Recv()显式确认就绪 - 流方法的 ServerStream 参数自带 context，别再额外传入其他 context
真正难的不是写通第一个 GetUser，而是让成百个微服务在高并发、弱网络、滚动发布下稳定交换数据。关键不在语法对不对，而在连接生命周期、context 传播路径、序列化边界这三处是否被真实观测和控制过。
