Golang Gin怎么做JWT登录认证_Golang Gin JWT教程【实用】

jwt.Parse后必须手动检查token.Valid，因其仅解析结构和解密签名，过期、篡改等校验依赖token.Valid；应使用ParseWithClaims配合嵌入jwt.RegisteredClaims的结构体，并确保密钥≥32字节且不硬编码。jwt.Parse 之后必须手动检查 token.Valid很多人以为 jwt.Parse 不报错就代表 token 合法，其实不然——它只做结构解析和签名解密，**过期、篡改、算法不匹配等校验都延迟到 token.Valid 字段才真正触发**。漏掉这一步，会导致已过期或被篡改的 token 仍被放行。错误写法：if err == nil { /* 直接放行 */ }正确写法：if err != nil || !token.Valid { c.AbortWithStatusJSON(401, gin.H{"error": "invalid or expired token"}) }注意：即使 err == nil，token.Valid 也可能是 false（比如 exp 已过，但没被校验）用 ParseWithClaims 而不是 Parse 绑定自定义字段想从 token 里安全取 user_id 或 role？别用 jwt.MapClaims 强转，它绕过标准字段校验，且无法自动验证 exp、iat 等时间字段。必须定义结构体并嵌入 jwt.RegisteredClaims：type CustomClaims struct { UserID uint `json:"user_id"` Role string `json:"role"` jwt.RegisteredClaims}解析时传指针 + 显式指定算法：jwt.ParseWithClaims(tokenStr, &CustomClaims{}, keyFunc, jwt.WithValidMethods([]string{jwt.SigningMethodHS256.Alg()}))若传值而非指针，或没嵌入 RegisteredClaims，ExpiresAt 就不会被自动校验密钥长度不够会静默截断，线上校验失败用 SigningMethodHS256 时，Go 的 crypto/hmac 底层要求密钥 ≥32 字节；若你硬编码 "my-secret"（仅 9 字节），本地可能“碰巧”通过，但线上环境因底层行为差异导致签名不一致，token 校验永远失败。生成合规密钥：openssl rand -base64 32，或用 make([]byte, 32) 配合 rand.Read密钥绝不能硬编码：从 os.Getenv("JWT_SECRET") 读取，开发/生产环境分别配置测试时可加断言：if len(secret) 登录接口返回 token 前，务必设 ExpiresAt 并区分 access/refresh 场景不设过期时间等于发长期通行证，一旦泄露无法主动回收；而把 access token 设成 7 天，又违背最小权限原则。 Cleanup.pictures 智能移除图片中的物体、文本、污迹、人物或任何不想要的东西