Go语言JWT认证核心是安全签发、校验、续期与废止；必须用golang-jwt/jwt/v5，显式设置UTC时间的exp/iat，嵌入RegisteredClaims，密钥≥32字节且从环境变量加载，验证时须同时检查err==nil和token.Valid。
Go 语言实现 JWT 登录认证，核心不是“怎么生成 token”，而是“怎么安全地签发、校验、续期和废止”——多数人卡在验证失败、exp 处理错乱、密钥硬编码或忽略时区差异上。
用 golang-jwt/jwt/v5 生成带 exp 和 iat 的 token
别用已归档的 dgrijalva/jwt-go，v5 版本修复了关键安全问题（如 alg:none 攻击），且 API 更清晰。生成时必须显式设置过期时间，且注意 time.Now().UTC() ——本地时区会导致验证时差异常。
实操建议：
TokenGX Cap 验证码【代码集成】技能 —— 面向开发场景，提供前端组件和后端验证的代码模板，帮助用户将 Cap 无感验证码快速集成到网站或应用中。适用场景：注册登录防刷、表单提交保护、API 接口防爬、发短信/邮件防滥用等。支持前端（HTML/React/Vue/Next.js）和后端（Node.js/Python/PHP/Go）全栈集成。触发词：集成验证码、添加人机验证、CAPTCHA 集成、cap widget、验证码前端、验证码后端、防刷表单等。与 tokengx-cap-admin（服务
-
jwt.NewWithClaims(jwt.SigningMethodHS256, claims)中claims必须是自定义结构体，嵌入jwt.RegisteredClaims（含ExpiresAt,IssuedAt,Subject等） - 密钥必须是
[]byte，长度建议 ≥32 字节；避免用字符串字面量如"my-secret"，应从环境变量加载 -
ExpiresAt要用jwt.NumericDate{Time: time.Now().Add(24 * time.Hour).UTC()}，不能直接传time.Time（v5 不支持）
claims := jwt.RegisteredClaims{
ExpiresAt: jwt.NumericDate{Time: time.Now().Add(24 * time.Hour).UTC()},
IssuedAt: jwt.NumericDate{Time: time.Now().UTC()},
Subject: "user:123",
}
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
signedToken, err := token.SignedString([]byte(os.Getenv("JWT_SECRET")))HTTP 中间件里验证 token 并提取 Subject
验证失败常见原因：header 名写成 X-Auth-Token（应为 Authorization: Bearer <token></token>）、没检查 err == nil 就直接取 token.Claims、忽略 Valid 字段判断。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 解析前先用
strings.HasPrefix(authHeader, "Bearer ")判断格式，再strings.TrimPrefix(authHeader, "Bearer ")提取 token 字符串 - 调用
jwt.ParseWithClaims(tokenStr, &claims, keyFunc)，keyFunc必须返回签名密钥（类型interface{}），不能直接传[]byte - 验证后必须检查
token.Valid为true，且err == nil；token.Claims是jwt.Claims接口，需类型断言为*jwt.RegisteredClaims - 把
Subject（如"user:123"）塞进context.WithValue(r.Context(), "subject", claims.Subject)供后续 handler 使用
为什么 ParseWithClaims 总返回 token is expired？
90% 是服务端时间不准或客户端/服务端时区不一致。JWT 的 exp、nbf、iat 全部按 UTC 秒级整数比较，time.Now() 若未强制 .UTC()，本地时区偏移会直接导致验证失败。
排查步骤：
- 打印服务端当前 UTC 时间：
log.Println("Now UTC:", time.Now().UTC().Unix()) - 解码 token payload（如用 jwt.io），看
exp值，换算成北京时间对比是否合理 - 确认 NTP 服务已启用：
timedatectl status（Linux）或systemsetup -getnetworktimeserver（macOS） - 避免在测试时用
time.Now().Add(-1 * time.Hour)模拟过期 —— 容易误判，改用固定时间戳调试
refresh token 怎么设计才不算“伪刷新”？
单纯延长 access token 过期时间不是 refresh；真正的 refresh 应包含：旧 token 加入短时效黑名单（如 Redis TTL=5min）、新 token 绑定设备指纹（User-Agent + IP）、且 refresh token 本身有独立过期（如 7 天）和单次使用限制。
关键点：
- access token 保持短时效（15–30 分钟），不存数据库；refresh token 存 Redis，key 为
refresh:{user_id}:{fingerprint_hash}，value 存发号时间与随机 salt - 每次 refresh 请求，先校验 refresh token 是否存在且未被使用，再删旧 record、发新 pair
- 不要把 user_id 直接写进 refresh token payload —— 它不该可被客户端解码，只作服务端索引用
- 前端必须在收到 401 后清空本地 access token，并用 refresh token 换新，成功后再重试原请求
真正难的不是代码，是 clock skew 控制、密钥轮转策略、以及 refresh token 泄露后的主动吊销路径 —— 这些几乎不会出现在“教程”里，但线上出问题第一个就栽在这儿。
