直接用 grpc.dial 无法实现透明化调用，因其不支持服务发现，需自定义 resolver.builder 并配置负载均衡策略；代理必须透传 context、metadata 和 call option，动态解析 proto 依赖反射与描述符缓存，性能瓶颈在于反射开销与流式场景处理。
为什么直接用 grpc.Dial 无法实现透明化调用
硬编码地址（比如 "localhost:9090"）在微服务里等于埋雷：服务一扩缩容、换节点、上K8s，客户端就炸。gRPC本身不带服务发现能力，grpc.Dial 默认只认固定地址，连DNS解析都得手动开 dns:/// 前缀，更别说从Consul/Nacos实时拉实例列表了。
常见错误现象：rpc error: code = Unavailable desc = connection refused 反复出现，但日志显示始终连同一台已下线的IP；或者新部署的服务永远收不到请求，因为客户端缓存了旧地址没刷新。
- 必须用自定义
resolver.Builder替换默认解析器，否则grpc.WithResolvers不生效 -
Build方法里不能阻塞——它在grpc.Dial同步执行，卡住就连接超时 - 返回的
resolver.State.Addresses必须是全新切片，GRPC会浅比较旧对象导致更新被忽略 - 要显式加
grpc.WithDefaultServiceConfig(`{"loadBalancingPolicy": "round_robin"}`)，否则即使多个地址也只打到第一个
动态代理层如何透传 context 和 metadata
代理若不手动搬运，trace_id、auth_token、超时 deadline 全部丢失。下游看到的是“裸请求”，链路追踪断在代理，超时判断失准，权限校验失败。
关键点在于拦截器里做两件事：从入参 context 提取原始 metadata，再注入到发往下游的 context 中。
- 用
metadata.FromIncomingContext读取上游传来的 header，注意 key 必须全小写（如"trace-id"），大写会被 Go gRPC client 自动丢弃 - 构造新 context 时用
metadata.NewOutgoingContext，不是context.WithValue - 超时信息藏在
ctx.Deadline()里，代理必须把原 context 透传下去，不能新建空 context - 别漏掉
grpc.WaitForReady(true)这类可选参数——它们也属于 call option，需原样转发
不用生成 stub 就能调用未知服务的核心机制
传统 gRPC 要求客户端提前有 .proto 文件生成的 Go 代码，动态代理绕过这一步靠的是反射 API 和协议缓冲区的运行时解析。
核心路径：收到请求 → 解析 service_name 和 method_name → 查服务注册中心拿到实例 → 拉取对应 .proto 描述符（从 Git/Buf Registry 或内存缓存）→ 动态构建 proto.Message 实例 → 序列化/反序列化。
- 依赖
grpc.ReflectionClient的ServerReflectionInfo流式接口，但生产环境常关闭反射服务，得 fallback 到中心化 proto 仓库 - 描述符加载后缓存到内存，避免每次调用都解析，但要注意 proto 版本冲突（如
foo.v1.Service和foo.v2.Service） - 方法签名不匹配时，错误信息是
"invalid message type for method"，不是网络错误，容易误判 - 二进制 payload 直接透传，代理不解析业务字段，只校验
Content-Type: application/grpc和 frame length
代理性能瓶颈和容易被忽略的细节
动态解析 + 反射 + 多次内存拷贝，会让代理延迟比直连高 1–3ms。这不是算法问题，而是 Go runtime 对 reflect.Value 和 proto.Unmarshal 的固有开销。
真正卡点往往在边界场景：长连接复用、流式 RPC、大 payload 分片、TLS 握手耗时。这些地方不细调，压测时 QPS 上不去，错误率飙升。
- 流式调用（
stream.UnaryServerInterceptor）必须透传grpc.Streamer接口，不能只处理 unary 场景 - HTTP/2 frame size 默认 16KB，大文件上传需在代理和上下游同时调大
grpc.MaxCallRecvMsgSize - 连接池管理：别用单个
grpc.ClientConn打所有后端，不同服务应隔离 conn，避免一个服务抖动拖垮全部 - 健康检查不能只 ping TCP 端口——得发一个轻量
health.Check请求，否则 DNS 缓存里挂着不可用实例
