Go中http.Handler链是事实上的装饰器模式，需返回新Handler、透传context、统一错误处理、严格控制中间件顺序，并通过路由器注册而非单个handler绑定。
Go 里没有装饰器语法，但 http.Handler 链就是事实上的装饰器
Go 没有 Python 那种 @decorator 语法糖，但鉴权这类横切逻辑，天然适合用 http.Handler 装饰器模式实现——把原始 handler 包一层，加完逻辑再调用它。
常见错误是直接在 handler 函数里写鉴权逻辑，导致每个接口重复判断、无法复用、中间件顺序混乱。
- 必须返回新的
http.Handler（或闭包函数），而不是直接修改原 handler - 装饰器要支持链式调用：
authMiddleware(loggingMiddleware(homeHandler)) - 注意
http.HandlerFunc和http.Handler接口的转换：传入函数需显式转成http.HandlerFunc(f)再调用ServeHTTP
func AuthMiddleware(next http.Handler) http.Handler 的标准写法
这是最常被抄错的一段。核心不是“怎么写 if”，而是“怎么透传请求上下文、怎么统一错误响应、怎么避免 panic 泄露敏感信息”。
典型场景：JWT 鉴权后要把用户 ID 注入 context.Context，下游 handler 才能取到。
立即学习“go语言免费学习笔记（深入）”；
- 别用全局变量存用户信息，必须通过
r = r.WithContext(context.WithValue(r.Context(), key, value)) - 鉴权失败时用
http.Error(w, "Unauthorized", http.StatusUnauthorized)，别用panic或裸写w.WriteHeader+w.Write - JWT 解析失败时，
jwt.Parse可能返回*jwt.Token但Valid == false，要双重检查 - 密钥轮换时，
jwt.Parse的KeyFunc必须支持多密钥验证，否则旧 token 立刻失效
多个中间件嵌套时，next.ServeHTTP 调用位置决定逻辑边界
顺序错了，鉴权就可能绕过。比如日志中间件放在鉴权前面，未授权请求也会被记录；而恢复 panic 的中间件如果放太后面，panic 就已经炸出去了。
真实错误现象：http: panic serving 127.0.0.1:8080: runtime error: invalid memory address —— 其实是鉴权失败后 handler 还继续执行，访问了 nil 用户对象。
- 鉴权中间件必须在业务 handler 之前，且
if !authorized { return }后不能调用next.ServeHTTP - recover 中间件应放在最外层（第一个装饰），否则内层 panic 会穿透出去
- 所有中间件的
defer日志记录，都该放在next.ServeHTTP调用之后，才能拿到真实状态码和耗时
用 gorilla/mux 或 chi 时，别混淆路由级和 handler 级装饰
有人把鉴权写成 r.HandleFunc("/api/user", authHandler(userHandler)).Methods("GET")，看似可行，实则破坏了中间件复用性，也绕过了框架对 OPTIONS 预检请求的自动处理。
正确做法是注册中间件到路由器实例，而非单个 handler。
-
chi：用r.Use(AuthMiddleware)，全局生效；或router.Group(func(r chi.Router) { r.Use(AuthMiddleware); r.Get(...)} ) -
gorilla/mux：没有原生Use，得手动包装子路由器：sub := r.PathPrefix("/api").Subrouter(); sub.Use(authMiddleware) - 别在
HandleFunc里 new 一个新 mux.Router 做子路由——这会丢失父 router 的中间件链
真正难的不是写一个鉴权函数，而是让错误不泄露、上下文不丢失、顺序不混乱、密钥可轮换。这些细节藏在每次 next.ServeHTTP 的前后两行里。
