JWT exp报错因时间戳单位错误Go的ExpiresAt需int64秒级时间戳误用UnixMilli()导致值过大被当作远期时间而判定过期密钥硬编码或加载不当亦引发验签失败。生成 JWT 时 exp 字段总报 expired因为时间戳单位错了Go 的 jwt.RegisteredClaims.ExpiresAt 必须是 jwt.NumericDate 类型底层是 int64 秒级 Unix 时间戳。直接写 time.Now().Add(1 * time.Hour).Unix() 是对的但若误用 UnixMilli()值会是毫秒比如 1740825123456验证器按秒解析就当成公元 5万 多年立刻判定过期。ExpiresAt: jwt.NewNumericDate(time.Now().Add(1 * time.Hour)) ? 推荐写法类型安全别用 map[string]interface{} 直接塞 exp: time.Now().Unix() ? 缺少类型断言v5 会静默忽略或 panic生成时没设 IssuedAt 或 NotBefore验证端启用 WithValidate(true) 可能因 iat/nbf 校验失败而拒收解析 token 总是返回 token.Valid false检查 keyFunc 和算法匹配调用 jwt.ParseWithClaims 后必须显式校验 token.Valid —— 解析成功不等于签名有效。常见原因是 keyFunc 返回了错误密钥、或未限制合法算法导致验签跳过。keyFunc 必须返回 []byte 密钥且不能返回 nil若从环境变量读确保 os.Getenv(JWT_SECRET) ! 务必在 ParseWithClaims 最后加 jwt.WithValidMethods([]string{jwt.SigningMethodHS256.Alg()})否则攻击者可篡改 header alg 为 HS384 绕过校验旧版 dgrijalva/jwt-go 存在 algnone 漏洞golang-jwt/jwt/v5 已移除该算法支持必须用带 /v5 后缀的包为什么中间件里取不到用户 IDclaims 结构体没嵌入 RegisteredClaims自定义 claims 如果只写字段、不嵌入 jwt.RegisteredClaimsv5 就不会自动触发 exp/iss/aud 等标准校验解析虽成功但 token.Claims 实际是空结构体字段全零值。正确结构type UserClaims struct { UserID string; jwt.RegisteredClaims } ?错误结构type UserClaims struct { UserID string; ExpiresAt int64 } ? 不触发任何时间校验且字段无法反序列化解析后必须用指针接收UserClaims{} 传给 ParseWithClaims否则字段赋值失败密钥硬编码在代码里上线就被扫出漏洞把 var jwtKey my-secret 写进源码等于把房门钥匙刻在门框上。Docker/K8s 环境下应优先挂载文件其次才考虑环境变量且要防命令行泄露。 Trenz AI驱动的社交电商营销平台专为TikTok Shop设计