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 权限检查。
立即学习“go语言免费学习笔记（深入）”；
注意 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），它们的中间件机制已内置中断逻辑，但底层仍是类似原理
复杂点在于，每个中间件都得对“流程是否继续”有明确判断，而不是依赖某种隐式控制流。这看起来啰嗦，但换来的是清晰、可测、无魔法。
