Go 语言虽无原生装饰器语法，但可通过高阶函数、接口和组合实现等效功能：函数类型适合轻量日志等简单场景，接口+结构体支持可配置的重试、超时等复杂逻辑，需注意 panic 捕获局限、context 透传、性能开销及关注点分离原则。
Go 语言没有原生的装饰器语法（比如 Python 的 @decorator），但完全可以通过高阶函数、接口和组合来实现等效的装饰器模式——关键不在“语法糖”，而在“行为增强”的意图是否清晰、可复用、不侵入原逻辑。
用函数类型实现最简装饰器
Go 中最轻量的装饰器，就是把一个 func() 或带参数/返回值的函数，包装成另一个函数，在调用前后插入横切逻辑：
type Handler func(string) stringfunc LoggingDecorator(h Handler) Handler { return func(s string) string { fmt.Println("→ entering with:", s) result := h(s) fmt.Println("← exiting with:", result) return result } }
// 使用 origin := func(s string) string { return "hello " + s } decorated := LoggingDecorator(origin) decorated("world") // 输出日志 + "hello world"
- 核心是返回新函数，而非修改原函数——符合 Go 的不可变习惯
- 注意闭包捕获的变量生命周期：若装饰器内部持有长生命周期资源（如数据库连接），需确保其释放时机可控
- 多个装饰器嵌套时，顺序直接影响执行流：
AuthDecorator(LoggingDecorator(h))表示先鉴权再打日志
用接口+结构体实现可配置装饰器
当需要传参、状态或复用多个装饰逻辑（如重试、超时、熔断）时，函数闭包会变得臃肿。此时应定义接口，并用结构体封装行为与配置：
type Service interface {
Do(string) (string, error)
}
type RetryDecorator struct {
inner Service
maxRetries int
}
func (r RetryDecorator) Do(s string) (string, error) {
var err error
for i := 0; i <= r.maxRetries; i++ {
if i > 0 {
time.Sleep(time.Second time.Duration(i))
}
if result, e := r.inner.Do(s); e == nil {
return result, nil
} else {
err = e
}
}
return "", err
}
- 必须让装饰器实现和被装饰者相同的接口（这里是
Service），才能无缝替换 - 构造时传入
inner Service，而非具体类型，保持依赖抽象 - 避免在装饰器结构体中暴露过多 setter 方法——配置应在初始化时定死，减少运行时不确定性
避免常见陷阱：panic 捕获、context 传递与性能开销
真实服务中，装饰器常要处理错误、取消、超时，但容易忽略几个关键点：
立即学习“go语言免费学习笔记（深入）”；
-
recover()不能跨 goroutine 生效：若被装饰函数启了新 goroutine 并 panic，外层装饰器无法捕获——需在子 goroutine 内部做 recover -
context.Context必须显式透传：不要在装饰器里硬编码context.Background()，而应要求被装饰方法签名含ctx context.Context，并在装饰器中转发 - 高频调用场景下，每层装饰器都新增一次函数调用和栈帧，对延迟敏感路径（如 HTTP 中间件链）建议用单个复合装饰器替代多层嵌套，或用
sync.Pool缓存临时对象 - 别用装饰器做本该由类型系统解决的事：比如“给字符串加颜色”这种纯数据转换，用工具函数更直观；装饰器更适合关注点分离明确的横切行为（日志、监控、认证）
真正难的不是写出一个能跑的装饰器，而是判断某段逻辑到底该作为装饰器存在，还是该下沉为业务方法的内置步骤——边界模糊时，优先选显式调用，而不是靠装饰链隐藏控制流。
