Go不支持方法装饰器，因方法非一等公民且无运行时反射修改机制；正确做法是通过接口+嵌入结构体实现装饰，或转方法为函数后用高阶函数包装。
Go 里没有“方法装饰器”这个东西——函数可以被包装，但结构体方法不能直接被 @xxx 修饰。你要扩展方法行为，得靠接口 + 嵌入结构体，或者把方法转成函数再装饰。
为什么不能直接装饰结构体方法
Go 不支持 Python 那种语法糖式的 @decorator，也没有运行时反射修改方法表的机制。所谓“方法装饰器”，本质是误用术语；真正能做的，是让方法所属类型实现某个接口，然后用另一个结构体包装它、实现同一接口，并在调用前后插入逻辑。
常见错误是试图写一个通用函数去“装饰任意方法”，结果只能靠 reflect，但会丢失类型安全、性能差、无法内联，还容易 panic。
- 结构体方法绑定在接收者上，不是一等公民，不能直接传参或返回
-
func(x *T) Foo()和func()()类型不兼容，无法统一签名 - 强行用反射包装，调试困难、逃逸分析失控、go vet 报告可疑代码
用接口+嵌入结构体实现方法级装饰
这是最 Go 的做法：定义最小接口，原始类型实现它，装饰器结构体持有该接口字段并重写方法。
立即学习“go语言免费学习笔记（深入）”；
比如你有个 DataLoader 类型，想加缓存和重试：
type Loader interface {
Load(key string) (string, error)
}
type RealLoader struct{}
func (r *RealLoader) Load(key string) (string, error) {
return fetchFromDB(key), nil
}
type CachedLoader struct {
next Loader
cache map[string]string
}
func (c *CachedLoader) Load(key string) (string, error) {
if val, ok := c.cache[key]; ok {
return val, nil
}
val, err := c.next.Load(key)
if err == nil {
c.cache[key] = val
}
return val, err
}
使用时：loader := &CachedLoader{next: &RealLoader{}, cache: make(map[string]string)} —— 它仍是 Loader，可替换原对象，且无额外类型断言。
- 装饰器必须依赖接口，不能依赖具体类型（否则破坏可替换性）
- 每个装饰器只做一件事：缓存就只管缓存，别掺权限校验
- 嵌入多个装饰器时，注意初始化顺序：外层装饰器的
next指向内层
把方法转成函数再用高阶函数装饰
如果原始方法逻辑简单、无状态，且你控制调用上下文，可以把方法值转成函数再包装：
type Service struct{}
func (s *Service) DoWork(input string) string {
return "result: " + input
}
// 转成函数
fn := func(s *Service, input string) string { return s.DoWork(input) }
// 但装饰器只能包装这个特定签名的函数，不是通用“方法装饰”
loggingDecorator := func(f func(*Service, string) string) func(*Service, string) string {
return func(s *Service, input string) string {
fmt.Println("before", input)
result := f(s, input)
fmt.Println("after", result)
return result
}
}
decorated := loggingDecorator(fn)
decorated(&Service{}, "test")
这适合测试或临时增强，但耦合了接收者类型和参数个数，无法泛化到任意方法。
- 签名固定：
func(*T, ...)和func(T, ...)是不同类型 - 每次都要手动提取方法为函数，不能自动推导
- 闭包捕获
*Service可能延长其生命周期，引发内存泄漏风险
HTTP Handler 是最典型的“伪方法装饰”场景
很多人以为 http.HandlerFunc 是方法，其实它是函数类型别名：type HandlerFunc func(http.ResponseWriter, *http.Request)。所以你能链式调用 loggingMiddleware(authMiddleware(handler))，是因为所有中间件都遵守同一函数签名，不是在装饰“方法”。
关键点：
-
http.HandleFunc内部把函数转成Handler接口，但装饰发生在函数层面 - 如果你自己写的服务结构体有
Handle(w, r)方法，想装饰它，得先让它实现http.Handler接口，再用标准中间件包装 - 不要试图写一个
DecorateMethod(&s, "Handle")—— 这是反 Go 的设计
真正难的不是怎么包装，而是决定哪些逻辑该抽成装饰器、哪些该留在业务里。状态管理、错误传播、context 传递这些细节一旦没对齐，链式调用就会崩掉——比如一个装饰器忘了调用 next()，整个链就静默失败。
