应选golang-jwt/jwt/v5，因jwt-go已归档且存在alg:none漏洞；golang-jwt修复安全问题、API更清晰、算法支持更全、错误类型更明确。
Token鉴权该用 jwt-go 还是 golang-jwt
直接选 golang-jwt/jwt/v5。原 jwt-go 项目已归档，v4 及之前版本存在未修复的 alg:none 绕过漏洞和反序列化隐患，且不再接收安全更新。golang-jwt 是社区维护的正式继任者，API 更清晰，对 Ed25519、RS384 等算法支持更完整，错误类型也做了区分（比如 jwt.ErrTokenExpired 而非笼统的 ValidationError）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化时显式指定签名方法：
jwt.SigningMethodHS256，避免依赖默认或运行时推断 - 解析 Token 必须校验
aud（受众）和iss（签发者），尤其在多租户或网关透传场景下 - 使用
ParseWithClaims并传入自定义jwt.Claims结构体，而非泛型map[string]interface{}，便于字段类型检查和 IDE 提示
如何在 Gin 中统一拦截并注入用户上下文
Gin 的中间件是自然选择，但关键在于「不提前解析、不重复解析、不泄露敏感字段」。常见错误是中间件里直接调 c.Set("user_id", ...) 后在 handler 里强转，一旦 Token 无效就 panic；或者每次请求都重新解析同一串 Token 字符串，浪费 CPU。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
c.Request.Header.Get("Authorization")提取 Bearer Token，空值或格式不符直接返回401 - 解析成功后，把完整
*jwt.Token和解析出的claims一起存入c.Request.Context()，而不是塞进c的键值对 —— 避免被下游中间件意外覆盖 - 写一个
MustGetUser工具函数，在 handler 内部安全取值：func MustGetUser(c *gin.Context) (uint64, error) { token, ok := c.Request.Context().Value("jwt_token").(*jwt.Token) if !ok || !token.Valid { return 0, errors.New("invalid token context") } claims, ok := token.Claims.(jwt.MapClaims) if !ok { return 0, errors.New("invalid claims type") } uid, ok := claims["uid"].(float64) if !ok { return 0, errors.New("missing or invalid uid claim") } return uint64(uid), nil }
Refresh Token 怎么设计才不被滥用
Refresh Token 不是延长 Access Token 有效期的快捷方式，而是用于可控的凭证轮换。典型陷阱是：把 Refresh Token 存在前端 localStorage、不绑定设备指纹、不限制单次使用、不记录失效时间。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Refresh Token 必须 HttpOnly + Secure + SameSite=Strict 的 Cookie 返回，禁止 JS 访问
- 数据库中需持久化存储其哈希值（如
sha256(refresh_token + salt)）、关联的user_id、expires_at和used_at（首次使用时间） - 每次用 Refresh Token 换新 Access Token 时，必须同时作废旧 Refresh Token，并生成全新的一对（即“滚动刷新”），防止长期泄露
- Access Token 过期时间建议 ≤ 15 分钟，Refresh Token 过期时间 ≤ 7 天，且登录态活跃时才允许刷新
服务间调用要不要再验 Token
要，但方式不同。内部服务（如 OrderSvc → UserSvc）若走内网直连，不应再走完整 JWT 解析流程，而应由 API 网关统一完成鉴权，并通过轻量 header（如 X-Auth-User-ID: 123、X-Auth-Role: "buyer"）透传可信身份信息。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 网关层验证 JWT 后，用内部密钥对用户 ID 和角色做一次短时效加密（如 AES-GCM，ttl=60s），写入
X-Internal-Authheader - 下游服务只解密并校验这个 header 的时效与 MAC，不查 Redis、不验签名公钥、不访问 Keycloak
- 禁止任何内部服务直接解析原始 Authorization header —— 这意味着它绕过了网关策略（如限流、审计、RBAC）
最易被忽略的是：跨服务传递时忘记清理原始 Authorization header，导致下游误以为这是终端用户直连，从而执行了不该有的权限逻辑。
