Golang装饰器实现日志权限叠加校验

Go中无装饰器语法，需用高阶函数组合中间件，如logMiddleware(authMiddleware("admin")(handler))，统一用func(http.HandlerFunc) http.HandlerFunc签名，通过context传参、显式return控制流程。

Go 里没有装饰器语法，得用函数式组合

Go 语言本身不支持 Python 那种 @decorator 语法，所谓“装饰器模式”在 Go 里本质是高阶函数 + 接口抽象。你真正要做的，是把日志、权限校验这些横切逻辑，封装成能接收并返回 http.HandlerFunc（或自定义 handler 接口）的函数。

常见错误是硬套 Python 思路，试图写个通用 Decorate 函数去“自动扫描”方法加标签——Go 没反射层面的运行时方法元信息，这条路走不通。

• 必须显式调用，比如 logMiddleware(authMiddleware(handler))
• 中间件顺序很重要：日志通常放最外层，权限校验紧贴业务 handler
• 所有中间件都得遵守同一签名，推荐统一用 func(http.Handler) http.Handler 或闭包形式的 func(http.HandlerFunc) http.HandlerFunc

用 http.HandlerFunc 嵌套实现日志 + 权限叠加

这是最轻量、最可控的做法，不需要额外接口或框架。每个中间件只做一件事，并返回新的 http.HandlerFunc。

典型场景：HTTP API 路由注册前，给某个 handler 叠加日志记录和 RBAC 权限检查。

注意 http.HandlerFunc 本质是类型别名，可直接被 http.Handle 接收，也方便嵌套：

func loggingMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        log.Printf("START %s %s", r.Method, r.URL.Path)
        next(w, r)
        log.Printf("END %s %s", r.Method, r.URL.Path)
    }
}

func authMiddleware(requiredRole string) func(http.HandlerFunc) http.HandlerFunc {
    return func(next http.HandlerFunc) http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
            role := r.Context().Value("user_role").(string)
            if role != requiredRole {
                http.Error(w, "Forbidden", http.StatusForbidden)
                return
            }
            next(w, r)
        }
    }
}

// 使用：从内到外套
handler := loggingMiddleware(authMiddleware("admin")(myBusinessHandler))
http.HandleFunc("/admin/users", handler)

• 参数差异：权限中间件需提前传入 requiredRole，日志中间件一般无参数
• 性能影响极小，只是函数指针传递，无反射或 interface{} 开销
• 容易踩的坑：authMiddleware("admin")(myBusinessHandler) 少一层括号就会编译失败

Context 传参比全局变量更安全

权限校验常需用户身份信息，但不能靠全局变量或闭包捕获 request —— 并发下会错乱。Go 的 context.Context 是唯一推荐方式。

常见错误现象：A 用户登录后，B 用户请求触发了 A 的权限判断，因为中间件里用了共享变量存 user ID。

• 登录成功后，用 context.WithValue(r.Context(), key, value) 注入角色或用户对象
• 中间件中统一从 r.Context().Value(key) 取，别依赖外部状态
• key 必须是 unexported 类型（如 type ctxKey int），避免和其他包冲突
• 不要把敏感字段（如密码、token）塞进 context，只放必要校验依据

error 处理和响应中断必须显式控制

装饰器叠加时，一旦权限校验失败，后续中间件和业务 handler 就不该执行。但 Go 的 http.HandlerFunc 没有“中断链”的语法糖，全靠提前 return。

最容易忽略的点：日志中间件如果写在最外层，权限拒绝后依然会打 “END” 日志，造成误判。

• 建议日志中间件也检查 response 是否已写（用 responseWriter 包装器判断 w.Header().Get("Content-Type") 不可靠）
• 更稳妥做法：让权限中间件自己打拒绝日志，日志中间件只记录“进入”和“正常返回”
• 不要在中间件里 panic，HTTP server 默认 recover 会吞掉 panic，导致错误静默
• 若用第三方 router（如 chi、gin），它们的中间件机制已内置中断逻辑，但底层仍是类似原理

复杂点在于，每个中间件都得对“流程是否继续”有明确判断，而不是依赖某种隐式控制流。这看起来啰嗦，但换来的是清晰、可测、无魔法。