Go中代理模式通过组合接口和结构体字段实现，代理类型需实现相同接口并在方法中控制调用逻辑；需注意避免nil panic、显式转发、用recover()捕获panic、用context.WithTimeout()控制超时。
nil panic、显式转发、用recover()捕获panic、用context.WithTimeout()控制超时。代理模式在 Go 中的核心实现方式
Go 语言没有类继承和接口强制实现机制，所以代理模式不靠“继承父类 + 重写方法”来实现，而是通过组合 interface{} 和结构体字段封装被代理对象。关键在于：代理类型必须实现与被代理对象相同的接口，且在方法中控制调用时机、参数、返回值或是否转发。
典型结构是：
- 定义一个接口（如
Service），包含业务方法（如Do()） - 真实类型（
RealService）实现该接口 - 代理类型（
AuthProxy）持有Service接口字段，并实现相同接口，在方法内插入访问控制逻辑
用嵌入式结构体 + 接口字段实现带权限校验的代理
这是最常用、最符合 Go 风格的做法。代理不隐藏原始对象，而是显式组合并控制其行为。常见错误是直接代理指针导致 nil panic，或忘记在代理方法中调用底层 Do()。
示例场景：只允许 admin 用户调用 Do() 方法：
立即学习“go语言免费学习笔记（深入）”；
type Service interface {
Do() string
}
type RealService struct{}
func (r *RealService) Do() string {
return "real work done"
}
type AuthProxy struct {
service Service
user string
}
func (a *AuthProxy) Do() string {
if a.user != "admin" {
return "access denied"
}
return a.service.Do() // 必须显式调用，否则不转发
}
// 使用：
svc := &RealService{}
proxy := &AuthProxy{service: svc, user: "guest"}
fmt.Println(proxy.Do()) // "access denied"
代理中如何安全处理 panic 和超时控制
真实服务可能阻塞或 panic，代理需兜底。Go 中不能像 Java 那样用 try-catch，但可用 recover() 捕获 panic，用 context.WithTimeout() 控制执行时间。忽略这两点会导致代理失效，变成单点故障。
-
recover()必须在 defer 中调用，且仅对当前 goroutine 有效 - 超时需将
context.Context注入被代理方法（即修改接口签名），或用time.AfterFunc异步中断（不推荐，难清理） - 若原接口无 context 参数，代理无法真正取消底层调用，只能提前返回错误
改进接口后示例：
type ServiceWithContext interface {
Do(ctx context.Context) (string, error)
}
func (a *AuthProxy) Do(ctx context.Context) (string, error) {
select {
case <-ctx.Done():
return "", ctx.Err()
default:
}
if a.user != "admin" {
return "", errors.New("access denied")
}
// 调用前设置子 context 防止泄漏
subCtx, cancel := context.WithTimeout(ctx, 2*time.Second)
defer cancel()
// 假设 realService 支持 context
return a.service.(ServiceWithContext).Do(subCtx)
}
为什么不要用函数式代理替代结构体代理
有人会写 func(Service) Service 类型的包装器，例如：
func WithAuth(s Service, user string) Service {
return &authWrapper{service: s, user: user}
}
这看似简洁，但问题明显：
- 每次包装都新建结构体，无法复用状态（如 token cache、计数器）
- 无法导出字段做配置（如
proxy.MaxRetries），失去可维护性 - 调试时难以识别类型（
fmt.Printf("%T", s)显示匿名类型） - 违反 “接收者语义清晰” 原则：代理行为属于结构体职责，不是临时转换
真正需要灵活链式代理时，应使用结构体字段组合多个策略（如 AuthProxy 内嵌 RateLimitProxy），而不是靠闭包层层套娃。
代理模式的复杂点不在语法，而在责任边界——谁校验权限、谁处理超时、谁记录日志、谁决定重试。这些必须在代理结构体内部明确划分，而不是堆砌 if 判断。
