Go 中间件顺序怎么定：鉴权、限流与日志装饰器的责任边界

线上订单接口最近突然冒出不少429告警，翻查日志却发现大把触发限流的请求连用户身份校验都没通过。Go 里的中间件不是随便堆叠上去就能跑的：日志、鉴权、限流和业务逻辑的排列顺序，直接决定了哪一步先消耗系统资源、哪些请求会被统计进监控指标，以及不同错误场景下返回的响应是否符合预期。

同一条请求链路，顺序不同会得到不同结果

先把中间件抽象成Go生态最常见的装饰器写法形态：

type Handler func(http.ResponseWriter, *http.Request)

func Chain(final Handler, layers ...func(Handler) Handler) Handler {
    for i := len(layers) - 1; i >= 0; i-- {
        final = layers[i](final)
    }
    return final
}

多个中间件组合的时候，写在最左侧的装饰器逻辑，会是请求进入后最先执行的那一层：

orders := Chain(
    orderHandler,
    RequestLog,
    RequireUser,
    RateLimit,
)

上面这个链路的最外层是日志中间件，接下来才校验用户身份，再进入限流逻辑最后执行业务代码。哪怕是匿名请求被直接拒绝，也能完整记录对应的request_id、请求路径和401返回结果，业务代码全程不会接触到未经过身份认证的非法请求。

鉴权与限流各管什么，不要互相越权

RequireUser 应该只关心请求携带的认证凭据合法性、对应用户身份，以及该用户是否有访问当前资源的权限。它不该顺手去修改限流的计数统计，更不能在用户配额超限的时候返回一个含义模糊的401状态码。

func RequireUser(next Handler) Handler {
    return func(w http.ResponseWriter, r *http.Request) {
        userID, ok := lookupUser(r.Header.Get("Authorization"))
        if !ok {
            http.Error(w, "unauthorized", http.StatusUnauthorized)
            return
        }
        ctx := context.WithValue(r.Context(), userKey{}, userID)
        next(w, r.WithContext(ctx))
    }
}

RateLimit 专门负责管控资源预算，比如按用户ID或者IP维度统计一分钟内的请求次数，请求超限的时候直接返回429状态码。两个模块逻辑完全拆分后，后续替换令牌桶算法、调整时间窗口规则的时候，完全不会触碰到身份校验的相关逻辑。

先限流还是先鉴权：看接口暴露面和运行成本

面向公网开放的普通接口，更推荐用「请求日志记录 → 鉴权校验 → 用户级限流 → 执行业务」的顺序。这种顺序下匿名请求不会占用正常用户的配额，鉴权失败的请求也会被明确标记成401状态存入日志。

但这不代表限流逻辑永远要放在鉴权后面。登录接口、签名校验接口或者大文件上传接口本身运行成本就很高，攻击者完全可以靠大量匿名请求直接打满CPU和连接池。这种场景就可以在最外层先加一个轻量化的IP粗粒度限流，之后再走日志记录和鉴权逻辑：

publicAPI := Chain(
    orderHandler,
    RequestLog,
    RequireUser,
    UserRateLimit,
)

protectedExpensiveAPI := Chain(
    importHandler,
    IPBurstLimit,
    RequestLog,
    RequireUser,
    UserRateLimit,
)

两层限流的职责完全不一样：IP粗限流负责直接保护服务入口，用户级限流负责管控不同用户的业务资源配额。别把两层逻辑都命名成 RateLimit，不然做代码评审的时候根本看不出令牌计数到底是在哪一层被消耗的。

日志应该记录什么，才不会把失败链路弄丢

日志中间件通常会包在所有逻辑的最外层，请求进入的时候生成或者继承上游传来的request_id，请求返回之前记录下最终状态码和接口耗时：

func RequestLog(next Handler) Handler {
    return func(w http.ResponseWriter, r *http.Request) {
        started := time.Now()
        rw := newStatusWriter(w)
        requestID := r.Header.Get("X-Request-ID")
        if requestID == "" {
            requestID = newRequestID()
        }
        rw.Header().Set("X-Request-ID", requestID)
        next(rw, r)
        log.Printf("request_id=%s path=%s status=%d cost=%s",
            requestID, r.URL.Path, rw.status, time.Since(started))
    }
}

如果把日志中间件放在鉴权逻辑后面，所有返回401的请求根本不会进入业务日志；如果把日志放在限流逻辑后面，线上最需要重点关注的429告警相关请求反而会缺失日志。只有在隐私管控要求非常严格的场景下，才需要裁剪日志字段，确保不记录敏感请求头部信息。

一个常见反例：中间件里偷偷做另一层的工作

下面这种写法看起来省了几行代码，实际会让各层的责任边界变得完全模糊：

func AuthAndLimit(next Handler) Handler {
    return func(w http.ResponseWriter, r *http.Request) {
        userID, ok := lookupUser(r.Header.Get("Authorization"))
        if !ok {
            http.Error(w, "unauthorized", 401)
            return
        }
        if !allow(userID) {
            http.Error(w, "too many requests", 429)
            return
        }
        next(w, r)
    }
}

短期看是少写了一个独立函数，后续维护的时候根本没法单独测试「鉴权失败会不会额外消耗限流配额」这类逻辑，也没法给不同路由单独替换不同的限流策略。中间件应该设计成一组可以自由重新排列的独立零件；如果两个逻辑从一开始就永远绑定在一起，后续组合复用的价值就完全消失了。

用三类请求验收顺序和副作用

• 匿名请求：预期返回401，不会进入订单查询等业务逻辑，也不会增加用户级的限流令牌计数。
• 同一用户连续发送超量请求：预期前N次请求可以正常返回结果，超出配额后返回429，每一条请求的日志都会带上对应的同一个request_id。
• 合法请求：预期正常进入业务逻辑，返回200状态码，日志会完整记录全链路耗时和最终状态码。

如果使用 httptest.NewRecorder，可以直接在单元测试里替换限流计数器和用户解析器的 mock 实现，单独验证每一层逻辑的调用次数。别只断言最终返回的状态码，「鉴权失败却偷偷消耗了用户配额」这类隐形副作用，往往才是线上莫名触发限流告警的根本原因。

常见问题

日志中间件一定要放最外层吗？

绝大多数HTTP服务都应该把日志中间件放在最外层，才能完整覆盖401、403、404、429和5xx等所有异常响应场景。如果日志需要做脱敏处理或者依赖用户身份字段，可以最外层的日志先保留request_id，内层处理完身份校验之后再补充上user_id字段到日志上下文。

限流场景下返回401还是429？

请求没有携带有效身份凭证的时候返回401；用户身份校验完全通过，只是请求量超出配额限制的时候返回429。不要用同一个状态码掩盖两种完全不同的错误原因，不然客户端逻辑和监控大盘都没办法正确识别和处理这两类场景。

中间件能不能直接修改请求Context？

完全可以，但Context里只适合存放当前链路需要的请求级数据，比如user_id和request_id这类信息。不要把可变的全局状态塞到Context里面，更不要用Context来替代明确透传的函数参数。

小结

中间件的顺序排布本质上就是在安排不同请求的失败成本和监控观测口径：日志层决定你能不能看见所有进入服务的请求，鉴权层决定谁才有资格继续往后走，限流层决定谁能消耗有限的系统资源，业务处理层只需要接收已经满足所有前置校验条件的合法请求。先把每个中间件的职责边界梳理清楚，再根据接口的暴露面和处理成本排列先后顺序，最后用匿名请求、超量请求、正常成功请求三类场景把顺序校验逻辑直接锁进单元测试里。