Go 语言虽无原生装饰器语法，但可通过高阶函数、接口嵌套和 HTTP 中间件实现横切关注点增强；关键在于保持签名一致、正确转发调用、避免阻塞与状态竞争，并利用 context 支持跨服务追踪。
Go 语言没有原生装饰器语法（如 Python 的 @decorator），但可以通过函数式组合、高阶函数和接口嵌套实现等效的功能增强逻辑——关键不在于“叫不叫装饰器”，而在于能否干净地叠加横切关注点（如日志、重试、熔断、指标采集）。
用高阶函数模拟装饰器行为
最常用且符合 Go 风格的做法：定义接收 func() 或 func(...interface{}) 并返回新函数的包装函数。它不侵入业务逻辑，支持链式叠加。
常见错误是直接在装饰器里调用原函数并忽略返回值或错误，导致下游无法感知执行结果。
- 装饰器应保持原函数签名，尤其是返回值类型和 error；否则调用方需适配，破坏可替换性
- 避免在装饰器中做阻塞型操作（如同步 HTTP 请求），除非明确这是设计意图
- 若需传参，用闭包捕获配置，而非硬编码——例如
withTimeout(3 * time.Second)比写死time.Second * 3更易测试和复用
func withLogging(next func() error) func() error {
return func() error {
log.Println("→ starting")
err := next()
if err != nil {
log.Printf("✗ failed: %v", err)
} else {
log.Println("✓ succeeded")
}
return err
}
}
<p>func withRetry(max int, next func() error) func() error {
return func() error {
var err error
for i := 0; i <= max; i++ {
err = next()
if err == nil {
return nil
}
if i < max {
time.Sleep(time.Second * time.Duration(i+1))
}
}
return err
}
}基于接口的装饰器：适合方法增强
当目标是一组具有相同接口的方法（如 Service 类型的多个方法），可定义包装结构体，内嵌原始实现，并选择性重写部分方法。这是 Go 中更面向对象风格的“装饰”方式。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑是忘记将未重写的方法委托给内嵌字段，造成空指针 panic 或逻辑丢失。
- 必须显式转发未增强的方法调用到
s.inner.Xxx()，不能依赖匿名字段自动提升（除非你确定所有方法都不需要拦截） - 装饰器结构体本身应实现同一接口，否则无法透明替换原实例
- 避免在装饰器中保存可变状态（如计数器），除非加锁——并发调用时会引发竞态
type Service interface {
Fetch(id string) (string, error)
Store(data string) error
}
<p>type loggingService struct {
inner Service
}</p><p>func (s *loggingService) Fetch(id string) (string, error) {
log.Printf("Fetch called with id=%s", id)
return s.inner.Fetch(id)
}</p><p>func (s *loggingService) Store(data string) error {
log.Printf("Store called with len=%d", len(data))
return s.inner.Store(data)
}</p><p>// 使用：&loggingService{inner: realService}HTTP Handler 装饰器：中间件模式最典型场景
http.Handler 和 http.HandlerFunc 天然支持装饰器链式调用，是 Go 中最成熟、最广泛使用的功能增强范式。
典型错误是忘记调用 next.ServeHTTP(w, r)，或在调用前/后误写 return 导致后续中间件或最终 handler 不执行。
- 每个中间件必须接受
http.Handler并返回新的http.Handler，才能构成标准链 - 顺序很重要：先注册的中间件最先执行（请求进入时），最后注册的最先响应（响应写出时）
- 不要在中间件里修改
*http.Request.URL或Header后不调用next.ServeHTTP，否则请求中断
func withAuth(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
token := r.Header.Get("Authorization")
if token == "" {
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return // ✅ 此处 return 是终止当前中间件，不影响链式结构
}
next.ServeHTTP(w, r) // ✅ 必须调用，否则下游不执行
})
}
<p>func withMetrics(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
next.ServeHTTP(w, r)
duration := time.Since(start)
log.Printf("req=%s dur=%v", r.URL.Path, duration)
})
}</p><p>// 使用：http.ListenAndServe(":8080", withAuth(withMetrics(handler)))真正难的是跨多个服务边界的一致性增强（比如分布式 trace ID 注入），这时单靠函数包装不够，得结合 context 传递和全局中间件注册机制。别只盯着“装饰器”名字，重点看数据流是否可控、可观测、可插拔。
