Go虽无装饰器语法，但可通过func值+接口+匿名结构体实现等效效果：以高阶函数Wrap返回新函数来增强行为，结构体携带状态并确保复用性与安全性。
为什么 Go 里没有装饰器语法，但 func 值 + 接口 + 匿名结构体就能凑出等效效果
Go 语言本身不支持 Python 那种 @decorator 语法，也没有方法级元编程能力。但装饰器模式的本质是「在不修改原函数逻辑的前提下，动态增强其行为」——这完全可以通过高阶函数和组合来实现。关键不是语法糖，而是控制权是否能交到调用链上游：把原函数当参数传给包装函数，再返回新函数，就完成了行为增强。
结构体方法在这里的作用，是提供一个可携带状态（比如日志前缀、重试次数、超时配置）的容器。比起纯函数闭包，结构体更易复用、测试和配置化。
-
func(http.Handler)是最典型的装饰器使用场景，http.HandlerFunc本身就是可调用的结构体方法载体 - 结构体字段可以存上下文依赖项（如
*log.Logger、time.Duration），避免闭包捕获变量生命周期问题 - 方法接收者用指针还是值，直接影响装饰器是否共享状态——多数时候你想要独立实例，所以用值接收者更安全
用结构体方法封装日志装饰器：注意 Do 方法签名与原函数对齐
假设你要装饰一个 func(string) (string, error) 类型的处理函数。不能直接让结构体方法也返回 (string, error)，否则无法被统一调用。正确做法是让结构体实现一个通用接口，并通过方法暴露符合目标签名的函数值：
type LogDecorator struct {
logger *log.Logger
prefix string
}
func (d LogDecorator) Wrap(f func(string) (string, error)) func(string) (string, error) {
return func(s string) (string, error) {
d.logger.Printf("%s: start %q", d.prefix, s)
defer d.logger.Printf("%s: done", d.prefix)
return f(s)
}
}
这里的关键点：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
Wrap不是直接执行逻辑，而是返回一个新函数——这是装饰器的核心契约 - 原函数
f被闭包捕获，确保每次调用都作用于同一份逻辑 - 如果需要支持多种函数签名（如带
context.Context的），就得写多个Wrap方法，Go 没有泛型函数重载，别试图用interface{}强转——运行时 panic 风险极高
多个装饰器串联时，顺序错误会导致 nil pointer dereference 或逻辑失效
装饰器嵌套本质是函数套函数：LogDecorator.Wrap(RetryDecorator.Wrap(original))。如果结构体字段未初始化（比如 logger 为 nil），在第一层调用时就 panic；更隐蔽的问题是，若重试装饰器依赖日志输出，但日志装饰器在它外层，那重试过程中的中间失败就不会被记录。
- 初始化检查必须在
Wrap内做，而不是构造结构体时——因为用户可能复用同一个装饰器实例包装不同函数 - 串联顺序应按「从外到内」理解：最外层装饰器最先执行进入逻辑，最后执行退出逻辑；最内层最先拿到输入，最后返回输出
- 不要在
Wrap中保存传入的f到结构体字段——这会让实例失去复用性，且容易引发 goroutine 安全问题
性能敏感场景下，避免在 Wrap 中分配堆内存或调用反射
每次调用 Wrap 都会生成一个新闭包，而闭包在 Go 中是堆分配对象。如果高频路径（如 HTTP 请求处理）每次都重新 Wrap，GC 压力会明显上升。解决方案是预构建装饰器实例并复用：
var jsonLogger = LogDecorator{
logger: log.New(os.Stdout, "[JSON] ", log.LstdFlags),
prefix: "json-process",
}
handler := jsonLogger.Wrap(decodeJSON)
// 复用 handler，而不是每次请求都 jsonLogger.Wrap(...)
另外，绝对不要在 Wrap 内使用 reflect.Value.Call 或 fmt.Sprintf 拼接日志消息——前者开销巨大，后者容易触发逃逸分析导致额外堆分配。用 logger.Printf 已足够轻量，且格式化发生在真正需要时。
真正容易被忽略的是错误传播：装饰器内部若吞掉原函数的 error（比如重试时只返回最后一次错误），上层就无法区分是业务错误还是重试耗尽。所有装饰器必须保证原函数的 error 类型和语义不被篡改，除非明确文档说明。
