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。
立即学习“go语言免费学习笔记（深入）”；
- 顺序敏感：先
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
}
真正难的不是写一个装饰器，而是设计出能自由组合、错误可控、职责清晰的装饰器链——它要求你从第一天就明确每个装饰器的边界：它该做什么、不该做什么、失败时怎么退。
