不少从Python或Ja va转过来的朋友，在Go里找装饰器，第一反应就是搜“@”符号，结果自然是扑了个空。Go语言的设计哲学里就没有“运行时函数替换”这一说，它更倾向于把事情做得简单、显眼。所以，所谓的“装饰器模式”在Go里，本质上就是一套用组合、接口和高阶函数拼凑起来的“组合拳”，而不是什么语法糖。
用惯Python的@log或@cache，在Go里确实会感觉不太顺手。所有“装饰”行为都得你亲手去调用、去组合，好处是逻辑一目了然，坏处是代码量会稍有增加。标准库里的http.StripPrefix、http.TimeoutHandler，其实就是最典型的装饰器——它们接收一个http.Handler，再返回一个http.Handler，干净利落。
核心模式：函数签名决定一切
在Go里模拟装饰器，最实用的模式就是func(http.Handler) http.Handler。这个签名本身就是一个契约：你传入一个处理器，它给你返回一个带有额外功能的处理器。输入和输出类型一致，才能实现链式调用，这是所有中间件架构的基础。
比如下面这个简单的日志中间件：
func LoggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
log.Printf("REQ: %s %s", r.Method, r.URL.Path)
next.ServeHTTP(w, r)
})
}
func AuthMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if r.Header.Get("X-Auth") == "" {
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return
}
next.ServeHTTP(w, r)
})
}
// 使用：顺序即执行顺序
mux := http.NewServeMux()
mux.HandleFunc("/", homeHandler)
handler := LoggingMiddleware(AuthMiddleware(mux))
http.ListenAndServe(":8080", handler)
你看，代码清晰、直接，没有黑魔法。每个中间件函数都只做一件事，组合起来就是一条完整的处理链。这其实比Python那种装饰器叠加更不容易出错，因为你完全可以控制执行顺序和上下文。
从闭包到结构体：当装饰器变复杂时
如果装饰逻辑很简单，比如日志、CORS，用闭包函数就足够了。但一旦逻辑变得复杂，需要配置超时时间、重试策略、或者要统计指标，闭包里的状态管理就会变得很麻烦。这时候，定义一个有状态的结构体，让它实现http.Handler接口，会是更明智的选择。
结构体比闭包好在哪？
- 可测试性：结构体的方法可以单独进行单元测试，不需要启动HTTP服务。
- 可配置性：你可以通过结构体字段保存配置，比如超时时间、重试次数，这些在初始化时设定，非常清晰。
- 可复用性：一个结构体可以轻松生成多个不同配置的装饰器实例。
注意，无论用哪种方式，你的装饰器必须实现http.Handler接口，也就是要有ServeHTTP方法，否则它无法接入标准的HTTP处理链路。
经验之谈：别在坑里翻车
真正考验功力的，从来不是怎么写一个装饰器，而是多个装饰器叠加时，怎么保证不出问题。这里有三个非常容易踩的坑：
- Context传递：如果你在装饰器里用
context.WithTimeout或context.WithValue创建了新的上下文，一定要记得用r = r.WithContext(...)更新请求对象，再传给下一个处理器。否则，你设定的超时、注入的trace ID，下一级中间件根本收不到。 - Panic处理：标准库的
http.Server默认会捕获panic，但如果你在自定义中间件里用了defer/recover，却没有重新panic，那错误就会被静默消化掉，线上排查时非常头疼。 - 数据共享：跨装饰器共享用户信息、请求ID等，最佳实践是通过
context.WithValue，而不是全局变量或闭包捕获。全局变量会引入竞态条件，闭包捕获则让代码逻辑变得混乱。
这些细节，如果不提前写在结构体或函数签名里，线上环境随时可能给你上一课。记住，Go语言的设计哲学是“显式优于隐式”，把逻辑写清楚，远比追求“看起来像装饰器”更重要。
