go中grpc必须严格遵循http/2与protobuf约束，否则易在并发、流控或错误传播上出错；需正确配置go_package路径、拦截器、健康检查、tls及流式context生命周期管理。
gRPC 在 Go 中不是“能用就行”的工具，而是必须按 HTTP/2 和 Protobuf 的约束来组织代码，否则很容易在并发、流控或错误传播上翻车。
proto 文件定义必须显式声明 go_package 且路径一致
生成的 Go 代码包路径和 import 路径不匹配，是 protoc 编译后最常导致 undefined: pb.XXX 或 cannot use ... as type pb.XXX 的原因。
-
go_package必须写成相对路径（如./userpb）或绝对模块路径（如github.com/yourorg/project/userpb），不能只写包名 - 生成命令中
--go_out和--go-grpc_out的输出目录要与go_package值对齐；例如go_package = "github.com/yourorg/project/userpb"，那生成目标就得是protoc --go_out=paths=source_relative:. --go-grpc_out=paths=source_relative:. user.proto - 如果项目用了 Go modules，
go_package强烈建议用完整模块路径，否则跨目录引用时go build会找不到包
服务端启动前必须注册拦截器和健康检查，否则上线即裸奔
默认的 grpc.NewServer() 不带任何可观测性能力，生产环境一旦出问题，连“服务是否存活”都难判断。
- 用
grpc.UnaryInterceptor和grpc.StreamInterceptor包裹日志、认证、超时逻辑，别在 handler 里重复写ctx.Done()判断 - 必须注册
grpc_health_v1.RegisterHealthServer，否则 Kubernetes 的 liveness/readiness probe 无法对接 - 别忽略
grpc.KeepaliveParams：高并发下连接空闲太久会被 LB 断连，设MaxConnectionIdle和Time可避免“连接复用失效却无感知”
客户端 Dial 时禁用 grpc.WithInsecure()，TLS 是默认要求不是可选项
本地开发用 WithInsecure() 看似省事，但一旦部署到集群，Kubernetes Service 或 Istio 默认拒绝明文 gRPC 流量，报错是 rpc error: code = Unavailable desc = transport is closing，而非明确提示 TLS 问题。
- 生产环境必须用
grpc.WithTransportCredentials(credentials.NewTLS(...)) - 自签名证书需额外配置
credentials.NewClientTLSFromCert(..., serverName)，其中serverName必须和证书 SAN 匹配，否则握手失败 - 若用 mTLS，服务端需同时设置
credentials.NewTLS(&tls.Config{ClientAuth: tls.RequireAndVerifyClientCert, ...})
流式 RPC 的 context 生命周期极易失控，必须手动控制 cancel
stream.Recv() 和 stream.Send() 都阻塞在底层 HTTP/2 stream 上，一旦上游 context 超时或取消，流不会自动关闭，goroutine 会泄漏。
- 所有流式 handler（
rpc ListUsers(...) returns (stream User)）开头必须调用ctx, cancel := context.WithCancel(ctx)，并在 defer 中cancel() - 每次
stream.Recv()后立即检查err == io.EOF或status.Code(err) == codes.Canceled，及时退出循环 - 客户端侧调用
stream.CloseSend()后，仍要继续stream.Recv()直到返回io.EOF，否则服务端流无法优雅终止
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
