Go中无装饰器语法，中间件链本质是func(http.Handler) http.Handler函数的嵌套组合，执行时形成隐式递归调用链，顺序与包装顺序相反，需确保每层调用next.ServeHTTP且正确传递r/w。
Go 中没有装饰器语法，但中间件链本质是函数式递归调用
Go 语言本身不支持 Python 那种 @decorator 语法，所谓“装饰器模式”在 HTTP 服务里实际是靠 http.Handler 类型的嵌套构造实现的——每次包装都返回一个新 Handler，而执行时层层调用，形成隐式递归链。
这不是编译期的装饰，而是运行时的函数组合。关键在于：每个中间件接收一个 http.Handler，返回另一个 http.Handler，最终把业务逻辑（比如 func(w http.ResponseWriter, r *http.Request)）塞进最内层。
- 中间件函数签名必须是
func(http.Handler) http.Handler，否则无法串起来 - 调用顺序和包装顺序相反：先
logMiddleware(authMiddleware(handler))，执行时是 log → auth → handler - 如果某个中间件忘了调用
next.ServeHTTP(w, r)，链就断了，后续所有中间件和最终 handler 都不会执行
手写中间件链时最容易漏掉的 return 和 defer
常见错误不是逻辑写错，而是控制流没兜住。比如日志中间件里忘记 return，或者 panic 恢复后没主动调用 next.ServeHTTP，导致请求卡死或重复响应。
典型翻车现场：
立即学习“go语言免费学习笔记（深入）”；
func recoverMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
http.Error(w, "Internal Error", http.StatusInternalServerError)
// ❌ 这里没 return，recover 后还会继续执行 next.ServeHTTP
}
}()
next.ServeHTTP(w, r) // ✅ 必须确保只执行一次，且在 defer 外围可控
})
}- 所有中间件内部的
next.ServeHTTP(w, r)前后都要检查是否可能被跳过（比如鉴权失败直接http.Error） - 涉及
defer的中间件，恢复 panic 后必须显式return，否则会二次响应（HTTP 会报http: multiple response.WriteHeader calls） - 不要在中间件里修改
r.URL.Path后不调用r = r.Clone(r.Context())，否则可能污染下游 context
用 slice 显式管理中间件比嵌套调用更可控
手动嵌套 m1(m2(m3(handler))) 看似函数式，但调试难、顺序反直觉、加/删中间件成本高。生产环境更推荐用 slice + 循环方式构建链路，等价于显式递归展开。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
核心思路：把中间件存成 []func(http.Handler) http.Handler，然后从右往左逐层包裹：
func chain(handlers ...func(http.Handler) http.Handler) func(http.Handler) http.Handler {
return func(final http.Handler) http.Handler {
for i := len(handlers) - 1; i >= 0; i-- {
final = handlers[i](final)
}
return final
}
}- 调用时顺序即执行顺序：
chain(logMW, authMW, metricsMW)(handler)→ log 先执行 - 便于动态增删：比如测试时去掉
authMW，只要改 slice 不用动嵌套结构 - 注意循环方向：从后往前包才能保证执行顺序与 slice 顺序一致；反过来就会颠倒
- 这个
chain函数本身不执行任何逻辑，只是生成新的Handler，所以性能无额外开销
中间件里访问原始请求上下文要小心生命周期
Go 的 http.Request 是单次使用的，中间件之间靠 r.Context() 传值，但 Context 是不可变的——每次 context.WithValue 都返回新 context，旧 context 不受影响。
常见误用：
- 在中间件 A 里做
r = r.WithContext(context.WithValue(r.Context(), key, val))，但没把新*http.Request传给下一层 → 下游取不到值 - 用全局变量存 request-scoped 数据 → 并发下数据错乱
- 在中间件里读
r.Body一次后没重放（httputil.DumpRequest就会吃掉 body），导致下游 handler 读到空 body
正确做法：所有中间件必须把改造后的 *http.Request 传给 next.ServeHTTP，且只通过 context.WithValue 传递只读元信息。
比如认证中间件注入用户 ID：
func authMW(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
uid := parseUID(r.Header.Get("X-User-ID"))
ctx := context.WithValue(r.Context(), userIDKey, uid)
r = r.WithContext(ctx) // ✅ 必须赋值回去
next.ServeHTTP(w, r) // ✅ 传入改造后的 r
})
}递归链的“深度”其实不体现在调用栈上，而是在 handler 嵌套层级里。真正容易出问题的从来不是层数，而是中间某一层悄悄截断、覆盖或丢弃了 request/response 的引用。写的时候多看一眼 next.ServeHTTP 调没调，调的是不是你认为的那个 r 和 w。
