如何在 Go 中实现基于 Token 的 API 鉴权中间件-Golang-PHP中文网

HTTP Handler链中Token验证必须前置，因ServeMux无拦截机制；需用中间件闭包包装handler，在业务逻辑前校验，否则可能触发副作用。

为什么 `http.Handler` 链里 Token 验证总在路由之后才生效

因为中间件顺序错了——go 的 http.servemux 不支持“前置拦截”，必须手动构造链式调用。如果你把鉴权逻辑写在 http.handlefunc 里，那它实际是路由处理函数的一部分，token 错误时已经进了业务逻辑，甚至可能触发数据库查询或副作用。

正确做法是用闭包包装原始 handler，让鉴权在进入业务前完成：

func AuthMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        authHeader := r.Header.Get("Authorization")
        if !strings.HasPrefix(authHeader, "Bearer ") {
            http.Error(w, "missing or malformed Bearer token", http.StatusUnauthorized)
            return
        }
        tokenStr := strings.TrimPrefix(authHeader, "Bearer ")
        if !isValidToken(tokenStr) { // 你自己的校验逻辑
            http.Error(w, "invalid token", http.StatusUnauthorized)
            return
        }
        next.ServeHTTP(w, r) // ✅ 只有通过才放行
    })
}

别用 http.ListenAndServe 直接注册 handler，先套一层 AuthMiddleware
如果用了第三方路由（如 gorilla/mux 或 chi），它们提供 Use() 或 With() 方法，本质也是同理
注意：http.Handler 和 http.HandlerFunc 类型不同，混用会编译失败

解析 JWT 时为什么 `ParseWithClaims` 总 panic

常见原因是没传入正确的 keyFunc，或者 key 类型和签名算法不匹配。JWT 库（如 github.com/golang-jwt/jwt/v5）在解析时不会立即报错，而是在调用 token.Valid 或访问 token.Claims 时 panic。

典型错误写法：

token, err := jwt.ParseWithClaims(tokenStr, &MyClaims{}, func(t *jwt.Token) (interface{}, error) {
    return []byte("wrong-key"), nil // ❌ 硬编码字符串，但算法是 HS256 才能用
})

HS256 要用 []byte；RS256 必须用 *rsa.PublicKey，且 keyFunc 需根据 t.Method.Alg() 动态返回
务必检查 err，再检查 token != nil && token.Valid，二者缺一不可
不要在 claims 结构体里嵌套指针字段（如 ExpiresAt *int64），JWT 库反序列化时可能静默失败

如何避免每个 handler 都重复提取 `userID` 到上下文

Token 验证成功后，用户身份信息（如 userID）应该塞进 context.Context，而不是靠全局变量或重读 header。否则下游 handler 得自己 parse、校验、取字段，既冗余又容易漏校验。

使用Go语言搭建家庭相册系统-相关课件

下载

推荐在中间件中完成注入：

type contextKey string
const userIDKey contextKey = "user_id"

// 在 AuthMiddleware 内部（验证通过后）
claims := token.Claims.(*MyClaims)
ctx := context.WithValue(r.Context(), userIDKey, claims.UserID)
r = r.WithContext(ctx)

next.ServeHTTP(w, r)

下游 handler 用 userID := r.Context().Value(userIDKey).(string) 拿值，注意类型断言要加判断
别用 context.TODO() 或 context.Background() 替换请求上下文，会丢掉超时、取消等关键信号
如果用了 OpenTelemetry，context 还承载 traceID，乱替换会导致链路断裂

Redis 存 Token 黑名单时为什么 `DEL` 操作总超时

不是 Redis 慢，而是 Go 客户端默认连接池太小，或没设超时。当大量注销请求并发打到 DEL，连接排队，最终触发 context.DeadlineExceeded。

初始化 redis.Client 时，显式配置 PoolSize（建议 ≥ 10）、MinIdleConns 和 Timeout（如 100ms）
黑名单 key 命名别用 "blacklist:" + token，Token 太长易导致 Redis 内存碎片；改用 sha256(token)[:16] 缩短
注销时用 SET key "" EX 3600 NX 替代 DEL，既能防重放又能控制 TTL，避免黑名单位置膨胀