一、为什么需要中间件/管道链#

你写了一个 HTTP 服务，最初只有业务逻辑。后来要加日志，就在处理函数开头写几行；要加认证，又在开头加一段校验；要加限流，再加一段计数逻辑。三个月后，业务逻辑被埋在几十行横切代码中间，改一个地方要翻半天。

更麻烦的是顺序问题。如果限流在认证之前运行，未认证的请求也会消耗限流配额，攻击者发一堆无效请求就能耗尽合法用户的配额。这种 bug 不是逻辑错误，而是代码组织方式导致的隐含依赖。

中间件/管道链把每个关注点抽成独立的中间件，按顺序串成链条。每个中间件只做一件事，然后调用 next() 把控制权交给下一个。不调用 next() 就短路整条链。请求向内流入，响应向外流出，形成「洋葱模型」。

二、现实类比#

机场安检通道。你的行李先过 X 光机（日志记录），然后过金属探测器（身份认证），再查验证件（参数校验）。每个关卡只做一件事，然后送你到下一个。任何一个关卡都可以拒绝你通过，相当于不调用 next() 短路整条链。

三、核心思想#

每个中间件接收一个上下文和一个 next() 函数。调用 next() 将控制传递给链中下一个中间件；next() 返回后，中间件可以运行后处理逻辑。不调用 next() 则短路整个链。这创建了一个双向管道，请求向内流入，响应向外流出。

执行顺序：A.pre → B.pre → C.pre → C.post → B.post → A.post。即使 B 短路（不调用 next()），A 的后处理仍然会执行，这就是为什么日志中间件即使对被拒绝的请求也能正确记录。

四、变体与对比#

五、多语言实现#

1
package pipeline
2

3
// Handler 是管道终端的处理函数
4
type Handler func(ctx map[string]any)
5

6
// Middleware 是中间件函数，接收上下文和下一个处理器
7
type Middleware func(ctx map[string]any, next Handler)
8

9
// Chain 将多个中间件组合为单一处理器
10
func Chain(middlewares ...Middleware) Handler {
11
    return func(ctx map[string]any) {
12
        var run func(i int)
13
        run = func(i int) {
14
            if i < len(middlewares) {
15
                // 将后续链包装为 next handler
16
                middlewares[i](ctx, func(c map[string]any) {
17
                    run(i + 1)
18
                })
19
            }
20
        }
21
        run(0)
22
    }
23
}

1
func logging(ctx map[string]any, next Handler) {
2
    start := time.Now()
3
    next(ctx) // 调用下游
4
    fmt.Printf("耗时: %v\n", time.Since(start))
5
}
6

7
func auth(ctx map[string]any, next Handler) {
8
    token, _ := ctx["token"].(string)
9
    if token == "" {
10
        ctx["error"] = "未认证" // 短路：不调用 next
11
        return
12
    }
13
    next(ctx)
14
}
15

16
// 业务处理器也需要符合 Middleware 签名（双参数），
17
// 在写入结果后调用 next(ctx) 把控制权交还上游做后处理
18
business := func(ctx map[string]any, next Handler) {
19
    ctx["result"] = "成功"
20
    next(ctx)
21
}
22

23
// 组合：日志 → 认证 → 业务处理
24
handler := Chain(logging, auth, business)

1
// 中间件类型：接收上下文和 next 函数
2
type Middleware<T> = (ctx: T, next: () => void) => void;
3

4
class Pipeline<T> {
5
  private middlewares: Middleware<T>[] = [];
6

7
  // 添加中间件到链尾
8
  use(middleware: Middleware<T>): void {
9
    this.middlewares.push(middleware);
10
  }
11

12
  // 执行中间件链
13
  execute(ctx: T): void {
14
    let index = 0;
15
    const next = (): void => {
16
      if (index < this.middlewares.length) {
17
        const mw = this.middlewares[index]!;
18
        index++;
19
        mw(ctx, next);
20
      }
21
    };
22
    next();
23
  }
24
}

六、生产验证#

• gRPC-Go — server.go#L1224-L1260 中的 chainUnaryServerInterceptors 将拦截器链接为单一处理器，getChainUnaryHandler 递归构建链，用于生产 gRPC 服务中的认证、日志、追踪和限流。
• Koa.js — application.js#L152-L204 中 use() 将中间件推入数组，callback() 通过 koa-compose 组合为单一函数。Koa 开创了异步洋葱模型，每个 await next() 创建一个栈帧，使下游中间件可以使用 try/catch/finally。
• Express.js — app.use() 链接中间件用于 HTTP 请求处理，是 Node.js 生态最广泛使用的中间件实现。

七、小结#

何时使用：

• HTTP 请求处理，认证、日志、CORS、压缩、限流作为可组合层
• RPC 拦截器，gRPC 拦截器用于追踪、认证、重试和指标
• 构建/编译管道，Webpack loader、Babel 转换各自处理后传递给下一个
• CLI 命令处理，参数解析、验证、帮助生成作为中间件

何时不用：

• 事件扇出（一对多），需要多个独立处理器响应同一事件时，用观察者模式
• 无状态转换，每步只是转换数据不需要包裹下一步时，用 array.map().filter().reduce()
• 性能关键热路径，每个中间件增加一次函数调用和闭包分配，紧密循环中开销不可忽视

八、参考资料#

• Koa 中间件机制 - 异步洋葱模型的原始实现
• gRPC-Go 拦截器链 - 生产级 RPC 中间件组合
• Express 中间件 - Node.js HTTP 中间件的事实标准
• Redux applyMiddleware - 状态管理中的中间件模式
• ASP.NET Core Middleware - .NET 请求管道实现