go中实现代理模式需依托组合、接口与函数值等特性，而非传统继承；常用接口+结构体组合实现静态代理，或用函数类型封装轻量级代理，避免反射开销。
Go 语言本身没有类继承和接口实现的动态绑定机制，也不支持传统面向对象语境下的代理模式（如 Java 中的 InvocationHandler），所以「在 Golang 中实现代理模式」不是套用设计模式教科书定义，而是用 Go 的组合、接口、函数值和反射等特性，解决实际问题：比如日志、重试、限流、缓存、权限校验等横切关注点的透明增强。
用接口+结构体组合实现静态代理
这是最常用、最清晰、性能最好的方式。核心是让代理类型和被代理类型实现同一接口，代理内部持有真实对象，并在方法调用前后插入逻辑。
常见错误现象：nil pointer dereference（忘记初始化代理结构体中的 real object 字段）；或代理方法里漏掉 return 导致返回零值。
使用场景：需要明确控制某几个方法的行为增强，且不希望引入反射开销。
立即学习“go语言免费学习笔记（深入）”；
示例关键点：
- 定义接口：
type Service interface { Do() string } - 真实实现：
type RealService struct{}+func (r *RealService) Do() string - 代理实现：
type LoggingProxy struct{ svc Service }+func (p *LoggingProxy) Do() string { log.Println("before"); r := p.svc.Do(); log.Println("after"); return r } - 注意：代理结构体字段类型必须是接口（
Service），不是具体类型（*RealService），否则无法替换实现
用函数类型封装实现轻量级行为代理
当目标不是“代理某个结构体”，而是“包装某个函数调用”，用函数类型更自然。Go 的函数是一等公民，适合做策略式代理。
参数差异：不需要定义接口或结构体，直接对 func() 或 func(int) error 等签名做包装。
性能影响：几乎没有额外开销，比反射快一个数量级。
示例：
type Handler func(string) (string, error)
func WithRetry(h Handler, maxRetries int) Handler {
return func(s string) (string, error) {
var err error
for i := 0; i <= maxRetries; i++ {
if result, e := h(s); e == nil {
return result, nil
} else {
err = e
}
}
return "", err
}
}
// 使用：handler := WithRetry(realFunc, 3)
容易踩的坑：WithRetry 内部没做 panic 捕获，若 h(s) panic，整个调用链崩；需配合 recover 才算完整代理。
用 reflect.Value.Call 实现泛型方法代理（慎用）
只有当你需要「对任意接口的任意方法统一加日志/耗时统计」，又不想为每个接口写一遍代理结构体时，才考虑反射。但它破坏了编译期检查，性能差，调试困难。
常见错误现象：panic: reflect: Call of unaddressable value（传入非指针接收者方法）；或 reflect: Call using zero Value（代理字段未初始化）。
使用前提：
- 被代理对象必须是指针（
reflect.ValueOf(&obj)） - 代理方法需通过
MethodByName获取，再用Call执行 - 所有参数和返回值必须转成
[]reflect.Value，极易出错
不建议用于生产核心路径。仅适合 CLI 工具、调试中间件等低频、可容忍开销的场景。
用 HTTP 中间件模拟代理模式（实际最常用）
Go 生态中，http.Handler 和 http.HandlerFunc 天然构成代理链。每个中间件就是一个代理：接收 Handler，返回新 Handler，在 ServeHTTP 前后插入逻辑。
典型错误：中间件里忘了调用 next.ServeHTTP(w, r)，导致请求终止；或修改了 *http.Request 但没用 r.WithContext 传递上下文变更。
示例结构：
func WithAuth(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !isValidToken(r.Header.Get("Authorization")) {
http.Error(w, "Forbidden", http.StatusForbidden)
return
}
next.ServeHTTP(w, r) // 关键：不写这行，代理就断了
})
}
这种模式之所以广泛，是因为它把「代理」从类型系统下沉到运行时调用链，既灵活又符合 Go 的组合哲学——但代价是类型安全弱化，需靠测试覆盖行为边界。
真正难的不是写出一个能跑的代理，而是决定在哪一层做代理：是包内函数调用？是 HTTP handler 链？还是 RPC 客户端拦截？不同层级的代理，对错误传播、上下文传递、可观测性埋点的要求完全不同。别为了套模式而代理，先想清楚你要拦截的是什么，以及谁该负责恢复。
