如何在Golang中实现装饰者模式_Golang装饰者模式功能扩展示例_技术教程

Go中装饰者模式用函数值链式包装或接口+结构体组合实现，避免继承模拟；函数式最轻量，结构体适合有状态场景，Option模式统一配置，核心是单一职责与接口隔离。

Go 语言没有类继承和接口实现的动态绑定机制，也不支持方法重载，所以传统的装饰者模式（如 Java 中通过继承 Component 并组合 Component 引用来叠加行为）在 Go 里不能照搬。但可以用函数值、接口嵌套和结构体组合来达成等效效果——关键是把“装饰”理解为对某个行为接口的包装增强，而非类型层级的扩展。

用函数类型封装行为并链式装饰

最轻量、也最符合 Go 风格的做法：把核心逻辑抽象为函数类型，装饰器本身也是同签名函数，接收原函数并返回新函数。

常见错误是试图用指针或结构体强行模拟“继承链”，反而让调用变笨重；正确思路是让装饰器专注做一件事：拦截、修改输入/输出、加日志、限流、重试等。

HandlerFunc 是典型例子，http.HandlerFunc 本质就是 func(http.ResponseWriter, *http.Request)
装饰器函数必须接收同类型函数作为参数，并返回同类型函数，否则无法链式调用
注意闭包捕获变量的生命周期——比如装饰器中缓存的配置应是只读或线程安全的

type HandlerFunc func(string) string
func WithLogging(next HandlerFunc) HandlerFunc {
return func(s string) string {
fmt.Printf("→ calling with: %q\n", s)
result := next(s)
fmt.Printf("← result: %q\n", result)
return result
}
}
func WithUppercase(next HandlerFunc) HandlerFunc {
return func(s string) string {
return strings.ToUpper(next(s))
}
}
// 使用：
handler := WithLogging(WithUppercase(func(s string) string {
return "hello " + s
}))
fmt.Println(handler("world")) // → calling with: "world" ← result: "HELLO WORLD"

用结构体+接口组合实现可配置装饰器

当装饰逻辑需要状态（如计数器、超时控制、配置字段），用结构体封装更清晰。此时“被装饰对象”通过接口注入，装饰器自身也实现同一接口。

容易踩的坑是让装饰器结构体直接持有具体类型（如 *MyService），这会破坏可替换性；必须依赖接口，且接口方法不宜过多，否则组合爆炸。

定义最小契约接口，例如 Processor 只含 Process(input string) (string, error)
每个装饰器结构体嵌入该接口字段（next Processor），并在自己的 Process 方法中调用 next.Process(...)
构造时传入下一层处理器，形成显式调用链，而非隐式递归

type Processor interface {
    Process(string) (string, error)
}
type LoggingProcessor struct {
next Processor
}
func (l *LoggingProcessor) Process(s string) (string, error) {
fmt.Printf("[LOG] start processing %q\n", s)
defer fmt.Printf("[LOG] done\n")
return l.next.Process(s)
}
type TimeoutProcessor struct {
next     Processor
duration time.Duration
}
func (t *TimeoutProcessor) Process(s string) (string, error) {
ctx, cancel := context.WithTimeout(context.Background(), t.duration)
defer cancel()
// 实际中需配合 channel 或 goroutine 处理超时，此处简化
return t.next.Process(s)
}
// 组装：
base := &SimpleProcessor{}
decorated := &TimeoutProcessor{
next:     &LoggingProcessor{next: base},
duration: 5 * time.Second,
}

避免接口膨胀：用 Option 模式统一配置入口

多个装饰器叠加后，初始化代码容易变成一长串嵌套构造，可读性差且难以复用。改用 Option 函数配合一个 builder 结构体，把装饰逻辑“注册”进去，最后一次性应用。

关键点在于：所有装饰器 Option 函数都操作同一个 builder 状态，而不是层层包裹实例；最终 Build() 才生成完整处理器。

Option 类型定义为 func(*Builder)，便于组合传递
Builder 内部维护原始处理器和装饰器列表，Build() 按顺序 apply 装饰器
不推荐在 Option 里直接执行副作用（如启动 goroutine），应延迟到 Build() 或首次调用时

type Option func(*Builder)
type Builder struct {
processor Processor
decorators []func(Processor) Processor
}
func NewBuilder(p Processor) *Builder {
return &Builder{processor: p}
}
func WithRetry(max int) Option {
return func(b *Builder) {
b.decorators = append(b.decorators, func(next Processor) Processor {
return &RetryProcessor{next: next, max: max}
})
}
}
func (b *Builder) Build() Processor {
p := b.processor
for _, dec := range b.decorators {
p = dec(p)
}
return p
}
// 使用：
p := NewBuilder(&SimpleProcessor{}).
Apply(WithLogging()).
Apply(WithRetry(3)).
Build()

真正难的不是写几个装饰器，而是判断什么时候该用装饰器、什么时候该用中间件、什么时候该拆成独立 service。Go 里过度设计装饰链，往往是因为没想清楚责任边界——比如错误处理本该由调用方决定，却塞进装饰器里硬转 panic；或者日志格式耦合了 HTTP 上下文，导致无法复用于 CLI 场景。保持每层装饰器单一、无状态、可测试，比堆砌模式更重要。