go中装饰者模式用函数值链式包装或接口+结构体组合实现，避免继承模拟；函数式最轻量，结构体适合有状态场景，option模式统一配置，核心是单一职责与接口隔离。
Go 语言没有类继承和接口实现的动态绑定机制，也不支持方法重载，所以传统的装饰者模式（如 Java 中通过继承 Component 并组合 Component 引用来叠加行为）在 Go 里不能照搬。但可以用函数值、接口嵌套和结构体组合来达成等效效果——关键是把“装饰”理解为对某个行为接口的包装增强，而非类型层级的扩展。
用函数类型封装行为并链式装饰
最轻量、也最符合 Go 风格的做法：把核心逻辑抽象为函数类型，装饰器本身也是同签名函数，接收原函数并返回新函数。
常见错误是试图用指针或结构体强行模拟“继承链”，反而让调用变笨重；正确思路是让装饰器专注做一件事：拦截、修改输入/输出、加日志、限流、重试等。
-
HandlerFunc是典型例子，http.HandlerFunc本质就是func(http.ResponseWriter, *http.Request) - 装饰器函数必须接收同类型函数作为参数，并返回同类型函数，否则无法链式调用
- 注意闭包捕获变量的生命周期——比如装饰器中缓存的配置应是只读或线程安全的
type HandlerFunc func(string) string
<p>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
}
}</p><p>func WithUppercase(next HandlerFunc) HandlerFunc {
return func(s string) string {
return strings.ToUpper(next(s))
}
}</p><p>// 使用：
handler := WithLogging(WithUppercase(func(s string) string {
return "hello " + s
}))
fmt.Println(handler("world")) // → calling with: "world" ← result: "HELLO WORLD"用结构体+接口组合实现可配置装饰器
当装饰逻辑需要状态（如计数器、超时控制、配置字段），用结构体封装更清晰。此时“被装饰对象”通过接口注入，装饰器自身也实现同一接口。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑是让装饰器结构体直接持有具体类型（如 *MyService），这会破坏可替换性；必须依赖接口，且接口方法不宜过多，否则组合爆炸。
- 定义最小契约接口，例如
Processor只含Process(input string) (string, error) - 每个装饰器结构体嵌入该接口字段（
next Processor），并在自己的Process方法中调用next.Process(...) - 构造时传入下一层处理器，形成显式调用链，而非隐式递归
type Processor interface {
Process(string) (string, error)
}
<p>type LoggingProcessor struct {
next Processor
}</p><p>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)
}</p><p>type TimeoutProcessor struct {
next Processor
duration time.Duration
}</p><p>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)
}</p><p>// 组装：
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)
<p>type Builder struct {
processor Processor
decorators []func(Processor) Processor
}</p><p>func NewBuilder(p Processor) *Builder {
return &Builder{processor: p}
}</p><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}
})
}
}</p><p>func (b *Builder) Build() Processor {
p := b.processor
for _, dec := range b.decorators {
p = dec(p)
}
return p
}</p><p>// 使用：
p := NewBuilder(&SimpleProcessor{}).
Apply(WithLogging()).
Apply(WithRetry(3)).
Build()真正难的不是写几个装饰器，而是判断什么时候该用装饰器、什么时候该用中间件、什么时候该拆成独立 service。Go 里过度设计装饰链，往往是因为没想清楚责任边界——比如错误处理本该由调用方决定，却塞进装饰器里硬转 panic；或者日志格式耦合了 HTTP 上下文，导致无法复用于 CLI 场景。保持每层装饰器单一、无状态、可测试，比堆砌模式更重要。
