Go中代理模式需通过接口+结构体封装+显式委托实现，核心是拦截与转发，安全控制必须手动嵌入；代理与真实对象同实现接口，调用方只依赖接口，避免直接持有具体类型如*http.Client；HTTP网络层代理（RoundTripper）与业务层代理职责分离；需注意panic捕获和错误包装以保障安全上下文。
Go 语言本身没有面向对象意义上的“代理模式”语法支持（比如 Java 的 java.lang.reflect.Proxy），但可以通过接口 + 结构体封装 + 委托调用，干净地实现代理逻辑；安全控制必须显式嵌入，不能依赖语言自动注入。
用接口定义被代理行为，避免直接暴露原始结构体
代理的核心是“拦截+转发”，前提是能统一操作入口。Go 中唯一可行的方式是让真实对象和代理对象实现同一接口，调用方只依赖接口，不感知背后是谁。
常见错误是让代理直接持有 *http.Client 或 sql.DB 等具体类型，导致无法拦截方法调用——这些类型没提供可覆盖的接口。
- 定义业务接口，例如
type DataFetcher interface { Fetch(id string) ([]byte, error) } - 原始结构体实现该接口（如
type HTTPFetcher struct{ client *http.Client }） - 代理结构体也实现同一接口，并在方法中做前置检查、日志、重试等
- 调用方只接收
DataFetcher接口值，运行时传入代理或原始实例均可
代理结构体中嵌入原始对象并控制调用链
代理不是装饰器，它需要决定是否、何时、以何种方式把请求交给真实对象。关键在于：不自动转发，而是在每个方法里显式判断和委托。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑是写成“透明代理”——比如在 Fetch 方法里无条件调用 p.real.Fetch()，那就失去了安全控制的意义。
type AuthProxy struct {
real DataFetcher
token string
}
func (p *AuthProxy) Fetch(id string) ([]byte, error) {
if !isValidToken(p.token) {
return nil, fmt.Errorf("unauthorized")
}
// 可在此处加日志、指标、超时控制
return p.real.Fetch(id)
}
HTTP 代理场景下别混淆 net/http.RoundTripper 和业务层代理
Go 标准库的 http.Transport 支持设置 Proxy 字段（如 http.ProxyURL），但这只是客户端发请求时的网络出口代理，和设计模式里的“代理模式”无关，也不涉及业务安全逻辑。
如果你要控制的是“哪些 API 路径允许调用”“请求头是否含有效签名”“响应敏感字段是否脱敏”，这些必须在业务逻辑层（即你自己的 handler 或 client 封装层）实现，而不是靠 RoundTripper。
-
http.Client的Transport是网络层代理，管“怎么发出去” - 你自己写的
AuthProxy是业务层代理，管“能不能发、发什么、怎么处理结果” - 两者可以共存，但职责绝不重叠
注意代理带来的 panic 传播与错误包装问题
代理方法如果直接返回 p.real.SomeMethod() 的结果，会把底层 panic 或原始错误原样透出，丢失上下文，也难以统一审计。
尤其在安全场景下，你不希望用户看到 database/sql: connection refused 这类信息，而应统一转为 "service unavailable" 并记录内部错误。
- 用
defer/recover捕获真实对象可能 panic 的方法（谨慎使用，仅限已知风险点） - 对返回的
error做二次判断：if errors.Is(err, ErrForbidden)，再决定是否透出或替换 - 用
fmt.Errorf("fetch failed: %w", err)包装错误，保留原始链路，但控制暴露粒度
代理模式在 Go 里不是语法糖，而是靠接口契约和显式委托构建的控制边界；安全控制不会自动附着，每一处 return p.real.Xxx() 都是你主动放弃防线的位置。
