go中无装饰器语法，需用函数类型手动组合；应定义专用签名确保类型安全，用闭包实现带状态中间件，注意串联顺序，避免反射和频繁内存分配以保障性能。
Go 里没有装饰器语法，但可以用 func 类型组合函数
Go 不支持 Python 那种 @decorator 语法，也没有类方法拦截机制，所以“装饰器”必须手动拼装。核心思路是：把原始函数看作一个 func(...interface{}) interface{} 或更具体的签名，再写一个包装函数，接收它、执行前置/后置逻辑、再调用它。关键不是语法糖，而是类型对齐——包装器和被包装函数得有兼容的输入输出。
常见错误是强行统一用 interface{} 做参数，结果丢失类型信息，运行时 panic 或需要大量断言。更稳妥的做法是为每类业务函数定义专用签名，比如：
type HandlerFunc func(*http.Request) *http.Response type Middleware func(HandlerFunc) HandlerFunc
这样中间件能静态检查类型，编译期就报错，而不是等请求进来才崩。
用闭包实现带状态的中间件（比如计数、日志 ID）
单纯套一层函数只能做无状态装饰，但实际中常要携带上下文数据，比如记录请求耗时、注入 trace ID。这时必须用闭包捕获外部变量，而不是把状态塞进全局或传参链。
-
MiddleWareWithCounter应该返回一个func(HandlerFunc) HandlerFunc，内部维护一个count int变量 - 每次调用返回的中间件时，它闭包里的
count是独立的，不会和其他中间件实例冲突 - 别在闭包里直接用
var count int——那会变成包级变量，所有实例共享
示例：
func NewCounterMiddleware() func(HandlerFunc) HandlerFunc {
var count int64
return func(next HandlerFunc) HandlerFunc {
return func(r *http.Request) *http.Response {
count++
log.Printf("request #%d", count)
return next(r)
}
}
}
多个中间件串联时，顺序错了会导致逻辑失效
Go 中间件链本质是函数嵌套：m1(m2(m3(handler)))。最外层中间件最先执行，最内层最后执行。比如日志中间件想记录完整耗时，就必须放在最外层；而身份校验中间件如果放在日志之后，就可能连非法请求都记进日志。
容易踩的坑：
- 用 slice 存中间件然后 for 循环 apply —— 这会变成并行调用，不是串行包装
- 手写
m1(m2(handler))但顺序写反，比如把auth放在logger内部，导致未认证请求也被计时 - 中间件里忘记调用
next，整个链就断了，handler 永远不执行
推荐做法：用一个 Chain 类型显式管理顺序：
type Chain struct {
middlewares []func(HandlerFunc) HandlerFunc
}
func (c *Chain) Then(h HandlerFunc) HandlerFunc {
for i := len(c.middlewares) - 1; i >= 0; i-- {
h = c.middlewares[i](h)
}
return h
}
性能敏感场景下，避免在中间件里做反射或频繁内存分配
HTTP 中间件在每个请求路径上都会执行，微小开销会被放大。常见低效操作：
- 用
fmt.Sprintf拼接日志字符串，不如用log.Printf("id=%s, path=%s", r.Header.Get("X-Request-ID"), r.URL.Path) - 在中间件里 new 结构体或 make map/slice，尤其当 handler 执行很快时，GC 压力反而来自装饰器本身
- 用
reflect.Value.Call统一调用任意函数 —— 失去编译期优化，且反射比直接调用慢 10 倍以上
真正需要泛化处理时，宁可多写几个签名一致的中间件函数，也不要为了“统一”引入反射。
切面逻辑越靠近业务签名，越不容易出错；越想抽象成通用工具，越容易在边界 case 上翻车。比如 recover 中间件必须针对具体 handler 签名写，不能指望一个 func(interface{}) interface{} 包住所有函数。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
