Golang代理模式实现与设计解析

积累知识，胜过积蓄金银！毕竟在Golang开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Golang代理模式实现与设计思路》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

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。但这已偏离标准代理模式，更接近装饰器或包装器的变体。

• 存 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() 取，这点容易被忽略。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。