Go虽无Python式装饰器语法，但可用高阶函数和闭包显式实现，需严格保持函数签名一致，适用于日志、重试等逻辑复用，但要注意性能开销与错误透传。
Go 里没有装饰器语法，但可以用高阶函数模拟
Go 不支持 Python 那种 @decorator 语法，也没法在运行时动态包装函数签名。所谓“装饰器”，本质是把一个函数传给另一个函数，返回新函数——这完全能用 Go 的函数类型和闭包实现，只是写法更显式、更啰嗦一点。
关键不是“像不像 Python”，而是“能不能复用逻辑”：比如统一加日志、测耗时、做重试。只要目标明确，Go 的写法反而更可控。
- 所有装饰器函数必须接收并返回相同签名的函数，比如
func(string) int，否则类型不匹配会编译失败 - 装饰器本身不是魔法，它只是构造闭包：内部捕获原始函数 + 额外逻辑，返回一个新函数值
- 别试图用
interface{}或反射绕过类型检查——性能差、易出错、IDE 失效
写一个带日志的 HTTP handler 装饰器
这是最常见场景：http.HandlerFunc 是标准接口，装饰器要保持签名一致，否则不能直接传给 http.HandleFunc。
错误写法是返回 func(http.ResponseWriter, *http.Request) 以外的类型；正确做法是严格复用原类型：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func WithLogging(next http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
log.Printf("START %s %s", r.Method, r.URL.Path)
next(w, r)
log.Printf("END %s %s", r.Method, r.URL.Path)
}
}
- 必须用
http.HandlerFunc类型断言或直接返回，不能省略类型声明，否则 Go 无法推导为 handler - 注意闭包捕获的是
next变量，不是调用时的值——多个 handler 共享同一个next没问题，因为每个WithLogging(f)调用都生成独立闭包 - 如果想在日志里加响应状态码，得用
ResponseWriter包装器（比如httptest.ResponseRecorder的思路），原生w写完就发出去了，没法事后读
多层装饰器嵌套时参数传递容易出错
比如先加日志、再加重试、再加熔断，一层套一层。问题不在语法，而在「谁该负责初始化上下文」和「错误是否被吞掉」。
典型陷阱：重试装饰器没把最终错误返回给上层，导致日志装饰器看到的永远是第一次调用的 error，而不是最后一次的。
- 每层装饰器只处理自己关心的逻辑，其余责任原样交给
next，包括返回值和 error - 避免在装饰器里做
if err != nil { return }这种提前退出——除非你明确要拦截这个 error - 如果需要透传额外数据（如 trace ID），别依赖全局变量或 context.WithValue 层层塞，而应在装饰器闭包里捕获初始
context.Context，再传给next
性能敏感场景下闭包开销不可忽略
高频调用的函数（如 JSON 序列化、字符串拼接）套装饰器，每次调用都会触发闭包环境查找，比直接调用慢 5%–15%，压测时可能暴露。
这不是理论问题：用 go test -bench 对比就能看出差距。尤其当装饰器内部有 map 查找、time.Now() 或 interface{} 转换时，延迟更明显。
- 对 QPS > 10k 的核心路径，优先考虑中间件注册模式（如 Gin 的
Use()），而不是每个 handler 单独 wrap - 避免在装饰器闭包里做初始化-heavy 操作，比如打开文件、建 DB 连接——这些应该提前提取到外层，作为参数传入装饰器工厂函数
- 如果只是加个计数器，直接用原子操作 + 全局变量比闭包更轻量，别为了“模式统一”牺牲可测性
真正难的不是写出能跑的装饰器，而是判断某段逻辑到底该放在 handler 内部、装饰器里，还是抽成独立 service。Go 的简洁性反而会让这个权衡更尖锐——没语法糖兜底，每行代码的意图都得特别清楚。
