如何使用Golang编写微服务的中间件？-Golang-PHP中文网

go http中间件本质是装饰器，签名必须为func(http.handler) http.handler；需闭包捕获原handler并调用next.servehttp(w, r)传递请求；推荐用结构体封装配置以提升可测性与复用性；stripprefix须置于中间件链最内层确保路径清理正确。

如何使用golang编写微服务的中间件？

中间件函数签名必须是 `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 当成中间件加在最外层，结果路径匹配失败。

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 或静默失败