Go 通过接口+函数式组合+结构体嵌入实现装饰者模式：先定义小而专注的接口，装饰器结构体嵌入该接口并重写方法委托增强，辅以工厂函数动态串联，需注意并发安全与逻辑边界。
Go 语言没有类和继承，也不支持传统面向对象意义上的装饰者模式（如 Java 中用抽象类 + 多层子类包装），但可以通过接口 + 函数式组合 + 结构体嵌套实现等效的动态行为扩展能力。关键不在于“模拟设计模式”，而在于用 Go 的惯用法解决「给已有类型安全、可复用地叠加新行为」的问题。
用接口定义能力契约，而非继承关系
装饰者模式的核心是「一致的接口」。在 Go 中，必须先定义清晰的接口，所有原始实现和装饰器都需满足它。常见错误是直接对具体结构体方法做装饰，导致类型断裂、无法链式叠加。
-
io.Reader和io.Writer是 Go 标准库最典型的装饰者友好接口：任何实现了Read([]byte) (int, error)的类型，都能被io.MultiReader、io.LimitReader等装饰 - 自定义接口应尽量小，只包含核心行为，例如：
type Processor interface { Process(data []byte) ([]byte, error) } - 避免让接口包含太多方法，否则装饰器需透传大量未增强的方法，违背“关注点分离”
用结构体字段嵌入原始实例，实现行为委托
Go 的结构体匿名字段（嵌入）天然支持“组合优于继承”。装饰器结构体通过嵌入被装饰对象，并重写部分方法，即可实现增强逻辑，其余方法自动透传。
- 装饰器结构体必须持有原始
Processor实例（通常为接口类型，非具体类型） - 重写方法时，在调用嵌入字段方法前后插入逻辑，例如日志、超时、重试
- 不要在装饰器里保存状态（如缓存 map），除非明确需要跨调用共享；否则易引发并发问题
type LoggingProcessor struct {
Processor // 嵌入，自动获得 Process 方法签名
}
<p>func (l LoggingProcessor) Process(data []byte) ([]byte, error) {
log.Printf("Processing %d bytes...", len(data))
defer log.Printf("Done processing")
return l.Processor.Process(data) // 委托给嵌入字段
}用函数返回装饰器，支持运行时动态组合
比起预定义多个装饰器类型，更灵活的方式是提供工厂函数，按需构造装饰链。这能避免类型爆炸，也便于测试和配置化。
ImageMagick 批处理处理器
下载
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
立即学习“go语言免费学习笔记（深入）”；
- 函数签名通常为
func(Processor) Processor，符合装饰器本质：输入一个处理器，返回增强后的新处理器 - 可串联调用：
WithTimeout(WithRetry(WithLogging(original))) - 注意顺序：越靠近原始实例的装饰器，越早执行（如
WithLogging在最内层，则日志最先打出来） - 若需传参（如超时时间），用闭包捕获：
func(timeout time.Duration) func(Processor) Processor
func WithLogging(next Processor) Processor {
return LoggingProcessor{Processor: next}
}
<p>func WithTimeout(timeout time.Duration) func(Processor) Processor {
return func(next Processor) Processor {
return TimeoutProcessor{
Processor: next,
timeout: timeout,
}
}
}</p><p>// 使用
p := WithTimeout(5 * time.Second)(WithLogging(original))小心闭包捕获与并发安全边界
装饰器看似轻量，但实际容易在高并发下暴露隐性缺陷。最常被忽略的是：装饰器本身是否线程安全？它持有的状态是否被多个 goroutine 共享？
- 如果装饰器结构体包含字段（如
sync.Mutex、map、计数器），必须确保所有访问都加锁或使用原子操作 - 避免在闭包中捕获可变变量（如循环变量
i），导致所有装饰器引用同一份值 - 标准库中的
http.Handler装饰（如http.StripPrefix）是线程安全的，因为它们不维护内部状态；你的自定义装饰器未必如此 - 用
go test -race验证装饰链在并发调用下的行为
真正难的不是写出一个能跑的装饰器，而是判断哪些逻辑适合抽成装饰器、哪些该直接写进业务方法里——比如「校验 token」适合装饰，「解析用户偏好并合并默认值」往往更适合放在 handler 内部。边界模糊时，优先选简单直白的实现。
