Go函数值通过闭包捕获原始函数与钩子实现代理逻辑，需保持签名一致、正确传参、透传返回值和context；HTTP中间件须封装ResponseWriter并注意执行顺序。
Go 函数值如何承载代理逻辑
Go 没有类、没有继承，但函数是一等公民，func 类型变量天然适合做代理的“中间层”。关键不是模仿 Java 的 Proxy 或 Spring AOP，而是用闭包捕获原始函数 + 前后钩子，把调用链显式串起来。
常见错误是试图用反射动态生成函数签名——没必要，也难维护。真实场景中，代理目标通常是已知接口或固定签名的函数，比如 http.HandlerFunc 或自定义的 Handler 类型。
- 代理函数必须与原函数签名一致，否则无法赋值给同一类型变量
- 闭包内调用原函数时，注意传参顺序和数量，漏传会导致 panic：
runtime error: invalid memory address or nil pointer dereference - 若需透传不定参数（如日志装饰器用于任意函数），用
interface{}+ 类型断言，但会丢失编译期检查
用闭包实现 AOP 风格日志装饰器
日志不是加在方法体里，而是套在函数调用入口/出口外层。典型模式是：接收一个 func() 或 func(...interface{})，返回一个新的 func()，执行前后打点。
例如对数据库操作加耗时日志：
立即学习“go语言免费学习笔记（深入）”；
func WithLog(fn func() error, op string) func() error {
return func() error {
start := time.Now()
err := fn()
duration := time.Since(start)
log.Printf("[LOG] %s took %v, err: %v", op, duration, err)
return err
}
}
// 使用
dbQuery := func() error { return db.QueryRow("SELECT ...") }
loggedQuery := WithLog(dbQuery, "user_fetch")
err := loggedQuery() // 日志自动打出
注意：WithLog 返回的是新函数，不是立即执行；若忘记调用返回值，日志永远不会输出。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 避免在闭包里直接打印
fn地址（如%p），它只是函数指针，无业务意义 - 若原函数有返回值需透传，不要只写
log.Printf后 return nil —— 会吞掉真实错误 - 高并发下频繁创建闭包对象可能影响 GC，可考虑复用结构体 + 方法代替纯闭包
HTTP 中间件作为动态代理的实际落地
Go 的 HTTP 服务天然适合代理模式：http.Handler 是函数类型别名，http.HandlerFunc 可被包装成带日志、鉴权、追踪的中间件链。
标准写法是链式调用，每个中间件接收 http.Handler 并返回新 http.Handler：
func LoggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
// 注意：需包装 ResponseWriter 才能捕获状态码和字节数
lw := &responseWriter{ResponseWriter: w, statusCode: 200}
next.ServeHTTP(lw, r)
log.Printf("%s %s %d %v", r.Method, r.URL.Path, lw.statusCode, time.Since(start))
})
}
// 使用：handler = LoggingMiddleware(AuthMiddleware(handler))
容易踩的坑是忽略 http.ResponseWriter 的封装。直接调用 w.WriteHeader() 会绕过中间件的状态记录，导致日志里的 status 总是 200。
- 必须用自定义
responseWriter包装原w，重写WriteHeader和Write - 中间件顺序很重要：日志放最外层，鉴权放内层，否则未授权请求也会被记日志
- 不要在中间件里 recover panic 后继续调用 next —— 可能导致重复写 response
性能敏感场景下的代理优化要点
函数代理本身开销极小，但日志 I/O、JSON 序列化、上下文传递会成为瓶颈。生产环境不能只图代码简洁。
几个关键取舍点：
- 日志级别控制：用
log.Level或 flag 判断是否启用，而非每次都构造字符串 - 避免在代理闭包里做耗时操作（如调用外部 API、读文件），否则阻塞整个调用链
- 如果只是记录 trace ID，优先从
r.Context().Value()取，而不是每次生成新 UUID - 高频接口（如健康检查）建议跳过日志代理，用路径前缀白名单过滤
最常被忽略的是 context 传递。代理函数若不显式将 context.Context 透传下去，下游超时控制、取消信号就全失效了 —— 日志再全也没用。
