在 Go Monorepo 项目中，引入一个内部 RPC 依赖本该是一件简单的事——加一行 require，配一个 replace，代码编译通过，似乎万事大吉。但服务一启动，直接 panic：

panic: proto: file "validate/validate.proto" is already registered
panic: proto: file "common.proto" has a name conflict over trpc.myservice.common.Team

两个 panic，两个不同的 proto namespace 冲突。这是 Go protobuf 生态中一个经典的「传递依赖地狱」问题。

本文记录一次真实问题的根因分析和解决方案：如何通过手写一个本地精简 Stub，以最小代码代价绕过 proto 注册机制，彻底消除冲突。

Kubernetes (K8s) 的 Service 是修路并挂牌子，而 Istio 的路由则是专业的交警和智能导航。虽然它们最终都能帮你找到对应的 Pod，但处理流量的方式完全不在一个维度。

背景问题

gRPC 以其高效的二进制序列化（Protocol Buffers）和强大的流式通信能力，已成为微服务间通信的主流选择。但在实际项目中，我们常常面临一个尴尬的局面：

• 内部服务用 gRPC 通信，高性能
• 对外开放 API 需要提供 HTTP/RESTful 接口，方便前端和其他语言调用
• 维护两套服务成本太高

有没有一种方式，可以让 同一个 gRPC 服务同时支持 gRPC 协议和 HTTP/RESTful 调用？

这就是 gRPC HTTP Transcoding 要解决的问题。