Go不支持运行时动态代理，因接口隐式实现且reflect无法创建新类型；Proxy模式需手动编写代理类型或用go:generate生成，典型做法是内嵌真实实例并委托调用。
Go 语言标准库没有内置的 Proxy 模式运行时代理生成机制（比如 Java 的 java.lang.reflect.Proxy），无法在运行时动态创建接口实现。所谓“Golang 中实现 Proxy 模式”，本质是手动编写代理类型，或借助代码生成工具（如 go:generate + goproxy 类工具）模拟行为——不是魔法，是约定与封装。
为什么 Go 不支持运行时动态代理
Go 的接口是隐式实现、无反射生成类型能力，reflect 包不能创建新类型或满足接口的结构体。你无法像 Java 那样调用 Proxy.newProxyInstance() 得到一个实现了某接口的代理对象。
-
interface{}和reflect.Value.Call()只能调用已有方法，不能“注入”新实现 - 所有满足接口的类型必须在编译期存在，且字段/方法签名完全匹配
- 试图用
unsafe或汇编绕过，既不可移植，也破坏类型安全，不推荐
手动实现 Proxy 模式的典型写法
对某个接口 Service，定义一个 ServiceProxy 结构体，内嵌真实实例（或远程 client），并在其方法中插入逻辑（日志、重试、鉴权、序列化/网络转发等）。
例如：
Bailian Usage Proxy
下载
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
立即学习“go语言免费学习笔记（深入）”；
type Service interface {
Do(string) (string, error)
}
type HTTPServiceClient struct {
baseURL string
}
func (c *HTTPServiceClient) Do(s string) (string, error) {
// 实际 HTTP 调用
return "", nil
}
type ServiceProxy struct {
client Service // 可以是本地实现，也可以是远程 client
}
func (p *ServiceProxy) Do(s string) (string, error) {
log.Println("Before Do:", s)
defer log.Println("After Do")
return p.client.Do(s) // 委托调用
}
- 代理类型必须显式实现全部接口方法，无法自动透传
- 若接口方法多，易漏写或忘记加代理逻辑；可用
go:generate配合mockgen或自定义模板生成骨架 - 注意：不要把
client设为interface{}——会丢失类型信息，导致无法调用具体方法
用于远程调用的 Proxy：gRPC / HTTP 客户端即天然代理
真正做远程调用时，你写的 client 本身就是 Proxy 模式体现：它隐藏了网络细节，暴露与服务端一致的接口。
- gRPC 的
pb.NewXXXClient(conn)返回的 client 就是典型的代理对象 —— 调用Do()实际触发 RPC 请求 - 用
net/http封装的 REST client（如带 token 自动注入、重试的APIClient）也是 Proxy - 关键不在“是否叫 Proxy”，而在是否解耦调用方与通信细节：如果业务代码只依赖
Service接口，而注入的是远程 client，那 Proxy 已经落地
容易被忽略的陷阱：零值代理与 panic
代理结构体字段未初始化就调用，极易 panic。尤其当代理持有可选中间件（如 middleware.Transport）或底层 client 为指针时。
- 不要写
var p ServiceProxy; p.Do("x")——p.client是 nil，调用时 panic - 构造函数应强制校验依赖：
func NewServiceProxy(c Service) *ServiceProxy { if c == nil { panic("client is nil") } ... } - 测试时务必覆盖 client 为 nil 的 case，否则上线后因 DI 错误导致静默崩溃
真正的难点不在“怎么写代理”，而在“如何让代理不成为维护负担”：接口变更时同步更新代理、避免代理层逻辑膨胀、清晰划分本地 stub 与远程 transport 职责——这些比语法技巧重要得多。
