Go中装饰者模式用函数值链式包装或接口+结构体组合实现，避免继承模拟；函数式最轻量，结构体适合有状态场景，Option模式统一配置，核心是单一职责与接口隔离。
Go 语言没有类继承和接口实现的动态绑定机制，也不支持方法重载，所以传统的装饰者模式（如 Java 中通过继承 Component 并组合 Component 引用来叠加行为）在 Go 里不能照搬。但可以用函数值、接口嵌套和结构体组合来达成等效效果——关键是把“装饰”理解为对某个行为接口的包装增强，而非类型层级的扩展。
用函数类型封装行为并链式装饰
最轻量、也最符合 Go 风格的做法：把核心逻辑抽象为函数类型，装饰器本身也是同签名函数，接收原函数并返回新函数。
常见错误是试图用指针或结构体强行模拟“继承链”，反而让调用变笨重；正确思路是让装饰器专注做一件事：拦截、修改输入/输出、加日志、限流、重试等。
-
HandlerFunc是典型例子，http.HandlerFunc本质就是func(http.ResponseWriter, *http.Request) - 装饰器函数必须接收同类型函数作为参数，并返回同类型函数，否则无法链式调用
- 注意闭包捕获变量的生命周期——比如装饰器中缓存的配置应是只读或线程安全的
type HandlerFunc func(string) stringfunc 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"
用结构体+接口组合实现可配置装饰器
当装饰逻辑需要状态（如计数器、超时控制、配置字段），用结构体封装更清晰。此时“被装饰对象”通过接口注入，装饰器自身也实现同一接口。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑是让装饰器结构体直接持有具体类型（如 *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 场景。保持每层装饰器单一、无状态、可测试，比堆砌模式更重要。
