Golang装饰器与中间件区别详解

小伙伴们对Golang编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《Golang装饰器与中间件区别及应用对比》，就很适合你，本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

HTTP中间件是装饰器模式的典型实现，因其通过函数接收并返回同类型handler，支持链式嵌套（如auth(log(metrics(handler)))），天然契合装饰器“无侵入增强”的本质。

Go 里没有 @decorator 语法，但「装饰器模式」和「中间件」本质是同一思想在不同抽象层级的落地——都是对某个行为（函数或接口方法）做无侵入的链式增强。

为什么 HTTP 中间件就是装饰器模式的典型实现

HTTP handler 的签名是 func(http.ResponseWriter, *http.Request)，而中间件如 loggingMiddleware、authMiddleware 都接收并返回同类型函数，完全符合装饰器定义：包装原逻辑，在前后插入横切关注点。

• 中间件链：auth(log(metrics(handler))) 就是多层装饰器嵌套，执行顺序严格遵循包装顺序
• 标准库 http.Handler 接口 + http.HandlerFunc 类型转换，天然支持函数式装饰
• Gin/echo 等框架的 Use() 方法，底层就是把中间件函数按序注入 handler 链，和 WithTiming(WithValidation(handler)) 逻辑一致

结构体嵌入 vs 函数式：什么时候该用哪种装饰器

选结构体嵌入还是函数式，关键看是否需要状态或复用逻辑；不是风格偏好，而是设计意图驱动。

• 用结构体嵌入（如 TimestampLogger）：当装饰器需携带配置（如日志级别、超时时间）、或需多次调用中保持内部状态（如计数器、连接池引用）
• 用函数式（如 WithRecovery）：适合无状态、一次性的增强，比如 panic 捕获、耗时统计、参数校验——轻量、易组合、测试友好
• 混用常见：基础服务用结构体实现，再用函数式中间件包一层，比如 http.HandleFunc("/api", WithMetrics(apiHandler))

容易踩的坑：装饰顺序、错误传播与接口一致性

装饰器不是“加功能”就完事，顺序错、错误没透传、接口不统一，会导致行为不可控甚至 panic。

• 顺序敏感：先 WithAuth 再 WithLogging，日志里才包含认证信息；反过来，未认证请求也会被记日志
• 错误必须透传：装饰器内调用 next() 后，不能吞掉 error（尤其在返回 error 的接口场景），否则上层无法感知失败
• 接口必须严格一致：所有装饰器和原始实现必须实现同一接口（如 Service.Process()），否则无法链式赋值，编译报错类似 cannot use ... as Service value

type Service interface {
    Process(data string) (string, error)
}

type BasicService struct{}
func (*BasicService) Process(data string) (string, error) {
    return "ok", nil
}

type LoggingDecorator struct {
    Service
}
func (d *LoggingDecorator) Process(data string) (string, error) {
    fmt.Println("before:", data)
    result, err := d.Service.Process(data) // 必须透传 err
    fmt.Println("after:", result)
    return result, err // 这行漏掉，上层永远收不到 error
}

真正难的不是写一个装饰器，而是设计出能自由组合、错误可控、职责清晰的装饰器链——它要求你从第一天就明确每个装饰器的边界：它该做什么、不该做什么、失败时怎么退。

本篇关于《Golang装饰器与中间件区别详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！