必须用github.com/golang-jwt/jwt/v5而非已归档且存在keyfunc漏洞的dgrijalva/jwt-go；v5强制显式处理算法与密钥，传错即panic，更早暴露问题。
为什么直接用 github.com/golang-jwt/jwt/v5 而不是老版本
新项目别碰 github.com/dgrijalva/jwt-go，它已归档且有未修复的 KeyFunc 逻辑漏洞（比如空字符串密钥被误判为合法）。jwt/v5 重构了验证流程，强制显式处理签名算法和 key lookup，避免默认行为引发的越权。你传错 SigningMethod 或返回 nil 的 keyFunc 会直接 panic，反而更容易暴露问题。
如何安全生成和校验 token，避开常见坑
JWT 本质是 Base64Url 编码的三段字符串，不加密、只签名——别把敏感字段塞进 payload；别用 HS256 硬编码密钥，生产必须从环境变量或 secret manager 加载；校验时必须检查 exp、iat、nbf，且 time.Now().UTC() 必须和 token 中时间字段用同一时区比对。
-
jwt.SigningKey必须是[]byte，不是字符串——[]byte(os.Getenv("JWT_SECRET"))才对 -
token.Valid只检查签名和基础时间字段，不校验自定义 claim（比如role），得手动读token.Claims后断言 - 解析时用
jwt.ParseWithClaims+ 自定义jwt.Claims结构体，别用jwt.MapClaims——后者无法做字段类型校验，容易 panic
怎样设计中间件让认证逻辑可复用又不污染 handler
Go 的 HTTP middleware 天然适合无状态认证：提取 Authorization: Bearer <token></token> → 解析 → 注入 context.Context → 后续 handler 用 ctx.Value 拿用户信息。关键点在于错误处理要分层：token 无效返回 401，过期或未生效返回 401，但 payload 缺失必要字段（如 user_id）应返回 403。
示例中间件核心逻辑：
func JWTAuth(secret []byte) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
auth := r.Header.Get("Authorization")
if auth == "" {
http.Error(w, "missing Authorization header", http.StatusUnauthorized)
return
}
tokenStr := strings.TrimPrefix(auth, "Bearer ")
token, err := jwt.ParseWithClaims(tokenStr, &CustomClaims{}, func(t *jwt.Token) (interface{}, error) {
if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
return nil, fmt.Errorf("unexpected signing method: %v", t.Header["alg"])
}
return secret, nil
})
if err != nil {
http.Error(w, "invalid token", http.StatusUnauthorized)
return
}
if !token.Valid {
http.Error(w, "token invalid or expired", http.StatusUnauthorized)
return
}
claims := token.Claims.(*CustomClaims)
ctx := context.WithValue(r.Context(), "user_id", claims.UserID)
next.ServeHTTP(w, r.WithContext(ctx))
})
}
}
refresh token 怎么和 access token 分开管理
JWT 本身无状态，所以 refresh token 必须有状态——存 Redis，带过期时间（比如 7 天），且每次使用后立即失效（delete + 新发）。access token 短期（15–30 分钟），refresh token 长期但受控。别把 refresh token 放 cookie 里还设 HttpOnly=false，XSS 一打就全丢。
- refresh 接口必须校验旧 refresh token 是否存在于 Redis，且对应 user_id 与 access token 中一致
- 签发新 access token 时，
exp应基于当前时间重算，不是沿用旧 token 的剩余时间 - 用户登出 = 删除 Redis 中该用户的 refresh token 记录，access token 无法主动废止，只能等它自然过期
复杂点不在代码量，而在时序和边界：token 解析失败是 401 还是 400？refresh 失败要不要清空旧 token？这些没写进标准，得根据业务定清楚，否则前端永远在猜后端想表达什么。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
