必须使用github.com/golang-jwt/jwt/v5，因其修复了alg=none绕过、cve-2023-37582等严重漏洞，强制显式算法校验与密钥长度要求，移除了不安全的signingmethodnone，并提供精确错误类型（如jwt.errtokenexpired），而旧版jwt-go已归档且存在真实线上风险。
为什么直接用 github.com/golang-jwt/jwt/v5 而不是老版本
老版本 github.com/dgrijalva/jwt-go 存在严重安全漏洞（如 alg: none 绕过、密钥混淆），且已归档不再维护。v5 版本强制校验签名算法、修复了关键逻辑缺陷，并支持更清晰的错误分类（比如 jwt.ErrTokenExpired 而非模糊的 ValidationError）。如果你还在用 v3 或 v4，升级不是可选项——是必须项。
ParseWithClaims 的三个参数怎么填才不 panic
常见错误是传入 nil 的 keyFunc，或返回了错误但没检查就继续解包。正确调用必须满足：密钥函数返回值非 nil、算法匹配、token 未过期且签名有效。示例中容易忽略的是 time.Now().UTC() 必须显式传入，否则默认用本地时区，导致过期判断偏差。
-
tokenString：从Authorization: Bearer xxx头里取到的原始字符串，注意去掉Bearer前缀 -
claims：必须是实现了jwt.Claims接口的结构体指针，比如&MyClaims{}，不能传值 -
keyFunc：返回密钥的函数，典型写法是func(t *jwt.Token) (interface{}, error) { return []byte("my-secret"), nil }；若用 RSA，需返回*rsa.PublicKey
如何安全地把用户 ID 放进 JWT payload
别把敏感字段（如密码哈希、邮箱全量）塞进 token。只放最小必要标识，比如 sub（subject）字段存用户 ID，类型限定为 string 或 int64。Gin 中常用方式是自定义 claims 结构：
type MyClaims struct {
jwt.RegisteredClaims
UserID uint64 `json:"user_id"`
Role string `json:"role"`
}
生成时用 jwt.NewWithClaims(jwt.SigningMethodHS256, MyClaims{...})；解析后强转回 *MyClaims 再取 UserID。注意：如果字段名大小写不一致或 tag 缺失，JSON 反序列化会静默失败，payload 看似正常但字段为空。
中间件里验证失败时该返回什么 HTTP 状态码
JWT 验证失败分三类，每种对应不同响应：
- token 格式错误（
malformed token）、签名无效（invalid signature）→401 Unauthorized - 过期（
token is expired）、未生效（token not active yet）→ 也用401，不要用403，因为这是认证失败，不是权限拒绝 - 算法不被允许（
algorithm is not supported）或密钥获取失败 →500 Internal Server Error，说明服务端配置异常，不该暴露给前端细节
真正容易被忽略的是：验证逻辑里一旦遇到 jwt.ValidationError，必须用 errors.Is(err, jwt.ErrTokenExpired) 这类精确判断，而不是用 strings.Contains(err.Error(), "expired") —— 错误信息可能随版本变化，且多语言环境会破坏匹配。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
