2. Go HTTP 中间件设计模式与链路执行顺序

在构建 OAuth2.0 令牌缓存与并发刷新中间件之前，必须深入理解 Go HTTP 中间件的核心设计模式。中间件是请求/响应链中的可插拔处理单元，它允许你在不修改核心业务逻辑的前提下，横切关注点（如认证、日志、限流、缓存）。本章将剖析 Go 标准库 net/http 与 gin 框架的中间件实现差异，并重点分析中间件链路的执行顺序——这是后续实现令牌刷新钩子与缓存穿透防护的理论基础。

2.1 Go HTTP 中间件设计模式

Go 中间件的核心模式基于 装饰器模式 与 责任链模式 的结合。一个中间件本质上是一个函数，它接收一个 http.Handler 并返回一个新的 http.Handler。这种模式允许你通过函数组合来构建处理管道。

2.1.1 核心接口与函数签名

标准库 net/http 定义了 Handler 接口：

type Handler interface {
    ServeHTTP(ResponseWriter, *Request)
}

中间件的通用签名如下：

type Middleware func(http.Handler) http.Handler

这种设计模式具有三个关键特性：

• 可组合性：多个中间件可以通过函数嵌套或链式调用来组合。
• 无侵入性：中间件不修改原始 Handler 的代码。
• 控制反转：中间件决定是否调用下一个 Handler，以及调用前后的逻辑。

2.1.2 洋葱模型与执行顺序

Go 中间件的执行顺序遵循经典的 洋葱模型。请求从最外层中间件进入，逐层向内传递，到达核心 Handler 后，响应再逐层向外返回。这种模型天然适合实现请求前预处理（如令牌验证）和请求后后处理（如缓存写入）。

2.2 net/http 与 gin 框架中间件对比

虽然 gin 框架底层基于 net/http，但两者在中间件的实现方式、上下文传递和性能特性上存在显著差异。理解这些差异对于选择正确的技术栈至关重要。

2.2.1 net/http 中间件实现示例

标准库的中间件实现需要手动管理 http.Handler 的嵌套：

// 日志中间件
func LoggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        log.Printf("[%s] %s %s", r.Method, r.RequestURI, time.Now().Format(time.RFC3339))
        next.ServeHTTP(w, r) // 调用下一个 handler
        log.Printf("[响应完成] %s", r.RequestURI)
    })
}

// 认证中间件
func AuthMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        token := r.Header.Get("Authorization")
        if token == "" {
            http.Error(w, "Unauthorized", http.StatusUnauthorized)
            return // 终止链式调用
        }
        // 将用户信息注入 context
        ctx := context.WithValue(r.Context(), "user", "user123")
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

// 组合中间件
handler := LoggingMiddleware(AuthMiddleware(finalHandler))

2.2.2 gin 框架中间件实现示例

gin 的中间件通过 gin.Context 提供更简洁的 API：

func LoggingMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        log.Printf("[%s] %s %s", c.Request.Method, c.Request.RequestURI, time.Now().Format(time.RFC3339))
        c.Next() // 调用后续中间件和 handler
        log.Printf("[响应完成] %s", c.Request.RequestURI)
    }
}

func AuthMiddleware() gin.HandlerFunc {
    return func(c *gin.Context) {
        token := c.GetHeader("Authorization")
        if token == "" {
            c.AbortWithStatusJSON(http.StatusUnauthorized, gin.H{"error": "unauthorized"})
            return // 终止链式调用
        }
        c.Set("user", "user123") // 注入上下文
        c.Next()
    }
}

// 注册中间件
r := gin.Default()
r.Use(LoggingMiddleware())
r.Use(AuthMiddleware())

2.3 中间件链路执行顺序深度分析

中间件的执行顺序直接影响令牌缓存与并发刷新机制的正确性。错误的顺序可能导致令牌在验证之前就被缓存，或者缓存刷新逻辑在请求处理完成后才执行。

2.3.1 执行顺序的三种模式

2.3.2 令牌缓存场景下的执行顺序设计

在 OAuth2.0 令牌缓存中间件中，推荐采用以下执行顺序：

1. 限流中间件（最外层）：防止缓存穿透攻击。
2. 令牌解析中间件：从请求中提取并验证令牌。
3. 缓存检查中间件：查询本地缓存，若命中则直接返回。
4. 业务 Handler（最内层）：处理实际业务逻辑。
5. 缓存写入后置逻辑：在响应返回后，异步更新缓存。

2.4 中间件链路中的错误处理与短路机制

在中间件链路中，错误处理和短路机制是保证系统健壮性的关键。对于 OAuth2.0 令牌缓存中间件，需要特别关注以下场景：

• 令牌无效：立即返回 401，不继续执行后续中间件。
• 缓存命中：直接返回缓存数据，跳过业务 Handler。
• 缓存穿透：允许请求到达业务 Handler，但需要设置并发控制防止缓存雪崩。
• 令牌刷新：在缓存未命中且令牌即将过期时，触发异步刷新机制。