Go 语言通过高阶函数和接口组合实现装饰器模式，而非原生语法糖；常用方式是定义统一函数类型并链式包装（如 WithLogging、WithTimeout），或对多方法结构体使用接口嵌入与方法重写。
Go 语言没有原生的装饰器语法（比如 Python 的 @decorator），所以你不能像在 Python 或 TypeScript 中那样直接“写个装饰器函数然后加个 @ 就完事”。但你可以用函数式编程和接口组合的方式，实现装饰器模式的语义和效果——关键是理解它要解决什么问题：在不修改原始逻辑的前提下，动态添加横切关注点（如日志、重试、超时、权限校验）。
为什么 Go 里不能直接用 @decorator？
Go 是显式、面向组合的语言，设计哲学上排斥隐式语法糖。它的函数是一等公民，支持闭包和高阶函数，但所有行为都必须显式调用、显式传递。这意味着：
-
func Decorate(f Handler) Handler这样的函数是可行的，但不会自动注入或拦截方法调用 - 没有类和方法绑定机制，所以无法像 Java Spring 那样基于反射代理方法
- “装饰”必须手动套一层，比如
Decorate(RealHandler)，而不是靠注解触发
如何用高阶函数模拟装饰器行为？
最常用也最符合 Go 风格的做法：定义统一的处理函数类型（如 http.HandlerFunc 或自定义 HandlerFunc），然后写多个接受并返回该类型的函数，层层包装。
例如，一个带日志和超时的 HTTP 处理链：
立即学习“go语言免费学习笔记（深入）”；
type HandlerFunc func(http.ResponseWriter, *http.Request)
func WithLogging(next HandlerFunc) HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
log.Printf("start: %s %s", r.Method, r.URL.Path)
next(w, r)
log.Printf("done: %s %s", r.Method, r.URL.Path)
}
}
func WithTimeout(timeout time.Duration, next HandlerFunc) HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), timeout)
defer cancel()
r = r.WithContext(ctx)
next(w, r)
}
}
// 使用：顺序很重要，越外层的装饰器越先执行
http.HandleFunc("/api", WithTimeout(5*time.Second, WithLogging(myHandler)))
- 装饰器函数本身不执行业务逻辑，只负责“包裹”和“增强”
- 调用顺序决定执行顺序：
WithTimeout(WithLogging(f))表示先设超时，再进日志；而WithLogging(WithTimeout(f))则相反 - 每个装饰器都应尊重
context传递，否则超时/取消会失效
什么时候该用接口组合替代高阶函数？
当你的“被装饰对象”不是简单函数，而是有多个方法的结构体（比如一个数据库客户端、一个消息发送器），这时更适合用接口 + 匿名字段组合，而非函数链。
例如：
type Sender interface {
Send(msg string) error
}
type BaseSender struct{}
func (b BaseSender) Send(msg string) error {
fmt.Println("sending:", msg)
return nil
}
type LoggingSender struct {
Sender // 嵌入接口，复用原有方法
}
func (l LoggingSender) Send(msg string) error {
log.Printf("before send: %s", msg)
err := l.Sender.Send(msg)
log.Printf("after send: %s, err: %v", msg, err)
return err
}
// 使用
sender := LoggingSender{Sender: BaseSender{}}
sender.Send("hello")
- 嵌入
Sender接口让LoggingSender自动获得未重写的方法签名 - 重写
Send方法时，显式调用l.Sender.Send，即“调用被装饰的原始实现” - 这种写法比函数链更易测试（可单独传入 mock 实现），也更容易扩展（比如加重试、熔断等新装饰器）
容易踩的坑：context 丢失、panic 传播、错误覆盖
装饰器看似简单，但在实际项目中常因细节失控导致行为异常：
- 忘记把装饰器内部创建的
ctx通过r.WithContext()传下去，导致下游ctx.Done()不生效 - 在装饰器里 recover panic 后没重新 panic 或返回错误，导致上游误以为操作成功
- 多个装饰器都修改同一响应头（如
w.Header().Set("X-Trace-ID", ...)），后设置的覆盖前设置的，且无冲突检测 - 用闭包捕获外部变量（比如
timeout）时，若该变量后续被修改，所有已创建的装饰器实例会共享最新值——这不是 bug，但容易被忽略
真正难的不是写出第一个装饰器，而是确保所有装饰器在并发、超时、错误、取消等边界条件下行为一致且可预测。建议每个装饰器单独单元测试，并在集成时验证组合顺序和上下文传递路径。
