go中闭包是实现装饰器的自然方式，适用于签名明确的函数（如http.handlerfunc），需避免泛型抽象、大对象捕获和未取消的context，推荐函数选项模式配置化。
Go 里没有装饰器语法，但闭包就是最自然的实现方式
Go 不支持 Python 那种 @decorator 语法糖，但这不代表不能做函数增强——闭包天然适合封装“在调用前后加逻辑”的行为。关键不是模仿语法，而是复用 func(...) 类型和高阶函数思维。
常见错误是试图写个通用 “装饰器工厂” 去套所有函数签名，结果被类型系统卡住：Go 没泛型函数重载，func(int) string 和 func(string, bool) error 是完全不同的类型，没法用一个统一接口接收。
- 只对明确知道签名的函数做包装，比如你清楚要增强的是
http.HandlerFunc或某个具体业务函数 - 把装饰逻辑写成独立函数，返回新函数，而不是试图抽象出“万能装饰器”
- 避免在闭包里捕获大对象（如整个 struct 实例），容易导致意外内存驻留
用闭包给 HTTP handler 加日志和耗时统计
这是最典型、最安全的装饰场景：http.HandlerFunc 类型固定，签名统一为 func(http.ResponseWriter, *http.Request)，闭包可以干净地包裹它。
func withLogging(next http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
log.Printf("START %s %s", r.Method, r.URL.Path)
next(w, r)
log.Printf("DONE %s %s in %v", r.Method, r.URL.Path, time.Since(start))
}
}使用时直接链式调用：http.HandleFunc("/api/user", withLogging(withAuth(userHandler)))。注意顺序：越靠外的装饰器越先执行（进入时）和越后执行（退出时）。
立即学习“go语言免费学习笔记（深入）”；
- 别在闭包里修改
w或r后还传给原 handler —— 比如提前调用w.WriteHeader()会导致后续 write 失败 - 如果需要捕获响应体内容（如做审计日志），得用
ResponseWriter的 wrapper 类型，而不是裸闭包 - 生产环境慎用
log.Printf，高频请求下 I/O 开销明显；考虑结构化日志库 + 异步写入
带参数的装饰逻辑：用函数选项模式传递配置
当装饰行为需要可配置（比如超时时间、开关标志），别把参数硬编码进闭包，也不要用全局变量。标准做法是让装饰器工厂函数接受配置参数，再返回闭包。
func withTimeout(d time.Duration) func(http.HandlerFunc) http.HandlerFunc {
return func(next http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
ctx, cancel := context.WithTimeout(r.Context(), d)
defer cancel()
r = r.WithContext(ctx)
next(w, r)
}
}
}调用：withTimeout(5 * time.Second)(userHandler)。这种两层函数嵌套看起来绕，但它把“配置生成器”和“装饰行为”清晰分离了。
- 不要把配置参数塞进闭包捕获的局部变量里（比如在外部定义
timeout := 5*time.Second再闭包引用），那样无法复用同一装饰器实例配不同值 - 注意
context.WithTimeout创建的子 context 必须被 cancel，否则可能泄露 goroutine - 如果配置项多（比如含重试次数、fallback 函数等），建议用 option struct + functional options 模式，比一堆参数更易维护
性能敏感场景下闭包装饰的开销在哪
每次调用装饰器工厂（如 withLogging）都会新建一个闭包值，本质是分配一个函数对象+捕获变量的指针。对高频调用函数（如每秒万级请求的 handler），这点开销可测但通常不致命；真正要注意的是闭包捕获的内容。
- 捕获指针（如
*sql.DB）没问题，但捕获大 struct 值会触发复制，增加 GC 压力 - 避免在闭包里启动 goroutine 并长期持有外层变量（如循环中为每个请求启 goroutine 却引用了循环变量
i），这是经典误用 - 如果装饰逻辑极轻量（比如只打一行 debug 日志），且调用频次极高，可考虑用 flag 控制是否启用，而非无条件包装
闭包本身不是银弹，它只是 Go 实现函数组合的底层机制。真正难的是厘清“谁该负责什么”——日志、认证、限流这些横切关注点，该由中间件统一管，还是由业务函数自己调？这比怎么写闭包更影响代码健康度。
