Go HTTP中间件本质是装饰器，签名必须为func(http.Handler) http.Handler；需闭包捕获原handler并调用next.ServeHTTP(w, r)传递请求；推荐用结构体封装配置以提升可测性与复用性；StripPrefix须置于中间件链最内层确保路径清理正确。
中间件函数签名必须是 func(http.Handler) http.Handler
Go 的 HTTP 中间件本质是装饰器，不是独立服务或插件。你写的函数必须接收一个 http.Handler，返回另一个 http.Handler，否则无法链式调用。常见错误是直接返回 http.HandlerFunc 而不包装原 handler，导致下游 handler 完全丢失。
正确写法的核心是闭包捕获原始 handler，并在内部调用 next.ServeHTTP(w, r)：
func loggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
log.Printf("Started %s %s", r.Method, r.URL.Path)
next.ServeHTTP(w, r) // 必须调用，否则请求中断
log.Printf("Completed %s %s", r.Method, r.URL.Path)
})
}
- 不能漏掉
next.ServeHTTP(w, r)—— 这是中间件“传递请求”的唯一方式 - 不要在中间件里提前
return或写响应体后还调用next.ServeHTTP，会 panic：http: multiple response.WriteHeader calls - 如果要修改请求（如解析 token），需用
r = r.WithContext(...)生成新 request，原r不可变
如何给中间件传参？用结构体封装比闭包更可控
带配置的中间件（比如 JWT 密钥、超时时间）容易陷入嵌套闭包陷阱：参数多时函数签名难读，测试难 mock，复用性差。推荐定义结构体 + 方法：
type AuthMiddleware struct {
SecretKey string
Realm string
}
func (m *AuthMiddleware) Handler(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
auth := r.Header.Get("Authorization")
if !validToken(auth, m.SecretKey) {
http.Error(w, "Unauthorized", http.StatusUnauthorized)
return
}
next.ServeHTTP(w, r)
})
}
- 初始化：
authMW := &AuthMiddleware{SecretKey: os.Getenv("JWT_SECRET")} - 使用：
http.Handle("/api", authMW.Handler(http.HandlerFunc(apiHandler))) - 好处：参数显式、可单元测试、支持依赖注入（比如把 DB 实例塞进结构体）
为什么 http.StripPrefix 和 http.ServeMux 顺序错了就失效？
中间件链执行顺序和路由注册顺序强相关。典型坑：把 http.StripPrefix 当成中间件加在最外层，结果路径匹配失败。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
正确姿势是让 StripPrefix 包裹最终 handler，而不是包裹中间件链：
// ❌ 错误：StripPrefix 在中间件外层，r.URL.Path 已被改写，后续中间件/路由逻辑错乱
http.Handle("/v1/", loggingMiddleware(http.StripPrefix("/v1/", apiMux)))
// ✅ 正确：StripPrefix 是最内层，确保路由匹配前路径已清理
http.Handle("/v1/", loggingMiddleware(authMW.Handler(http.StripPrefix("/v1/", apiMux))))
-
http.StripPrefix返回的是http.Handler，它只负责改写r.URL.Path，不参与中间件逻辑 - 所有中间件（日志、鉴权、限流）都该作用于“清理后”的请求，所以必须包在
StripPrefix外侧 - 用
http.ServeMux时，注册路径必须和StripPrefix前缀一致，否则 404
gorilla/mux 和原生 http.ServeMux 对中间件的支持差异
原生 http.ServeMux 没有内置中间件机制，所有中间件必须手动链式包裹；gorilla/mux 提供 Router.Use()，但底层仍是同一种装饰模式，只是语法糖。
关键区别在路由粒度：
- 原生 mux：中间件作用于整个子路径，比如
/v1/下所有 handler -
gorilla/mux：可用router.PathPrefix("/admin").Subrouter().Use(adminMW)精确控制范围 - 但注意：
Use()注册的中间件仍遵循func(http.Handler) http.Handler签名，不是任意函数 - 混用时别把
gorilla/mux的Router直接丢给原生http.Handle—— 它实现了http.Handler接口，但内部路径匹配逻辑不同，可能导致 panic 或静默失败
真正容易被忽略的点是 context 传递：中间件里塞进 r.Context() 的值，在下游 handler 中必须用 r.Context().Value(key) 显式取，且 key 类型最好用自定义类型避免冲突，而不是随便用字符串。
