Go中代理模式用组合+接口契约实现：定义公共接口，真实对象和代理对象均实现它，代理内部持有接口类型字段；避免嵌入结构体或存储具体类型指针，除非需访问非接口方法。
代理模式在 Go 里没有接口继承，怎么写？
Go 没有传统 OOP 的继承和抽象类，所以不能靠“让代理类继承目标类”来实现。核心思路是：用**组合 + 接口契约**——定义一个公共接口，让真实对象和代理对象都实现它，再由代理对象内部持有真实对象的实例。
常见错误是试图用结构体嵌套“模拟继承”，比如 type LoggingProxy struct { RealService }，这会导致方法集不一致（嵌入字段的方法不会自动加入接口实现），反而破坏代理逻辑的可控性。
- 必须先定义接口，例如
type Service interface { Do() string } - 真实类型实现该接口：
type RealService struct{}+func (r RealService) Do() string - 代理类型也实现同一接口，但内部封装真实对象：
type LoggingProxy struct { svc Service } - 代理的
Do()方法里可前置/后置逻辑，再调用p.svc.Do()
什么时候该用 struct 字段存 *RealService，而不是 Service 接口？
绝大多数情况下，代理结构体字段应该保存接口类型（如 svc Service），而非具体类型指针。否则会强耦合，失去代理的解耦价值，也难以替换真实实现（比如换成 mock 或 fallback）。
唯一例外是需要访问真实类型的**非接口方法**（比如配置字段、私有状态、未导出方法），此时才考虑存 *RealService。但这已偏离标准代理模式，更接近装饰器或包装器的变体。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 存
Service接口 → 支持任意符合接口的实现，便于测试和替换 - 存
*RealService→ 可调用其未暴露在接口外的方法，但丧失多态性和可插拔性 - 若真需要两者兼顾，可用类型断言临时转换：
if rs, ok := p.svc.(*RealService); ok { ... }，但应尽量避免
代理里加日志/鉴权/重试，为什么 panic 后容易漏掉 recover？
代理的典型用途是横切逻辑，但 Go 的 defer/recover 只对当前 goroutine 生效。如果代理方法里启动了新 goroutine（比如异步上报日志），或调用了可能 panic 的第三方库且没包一层 recover，panic 就会穿透出去，导致整个服务崩溃。
尤其注意 http.HandlerFunc 类代理（如中间件）：goroutine 是由 http.Server 启动的，代理函数本身不是 goroutine 入口，recover 必须放在最外层 handler 内部。
- 所有代理方法入口处，如需容错，应加
defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }() - 避免在代理中直接起 goroutine 调用下游；若必须，每个 goroutine 都要独立 recover
- 重试逻辑不要无条件递归调用自身（如
p.Do()），易栈溢出；改用 for 循环 + context 控制
HTTP 中间件算代理模式吗？怎么写出可链式代理的结构？
是的，func(http.Handler) http.Handler 这种签名就是典型的函数式代理。每个中间件接收原 handler，返回新 handler，在 ServeHTTP 中插入逻辑，完全符合代理定义。
链式的关键是让每个代理只关心“自己那层”，不感知上下游具体类型。不要试图把多个中间件塞进一个 struct，而要用闭包或函数组合。
- 标准写法：
next := authMiddleware(loggingMiddleware(realHandler)) - 每个中间件形如：
func loggingMiddleware(h http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { ... h.ServeHTTP(w, r) }) } - 注意顺序：越靠外的中间件越早执行（如日志在最外层能看到完整耗时，鉴权在外层能拦截非法请求）
真正难的是错误传递和上下文透传——比如鉴权中间件想把用户 ID 注入 context，后续 handler 必须显式从 r.Context() 取，这点容易被忽略。
