golang-jwt/jwt/v5 不参与 OAuth2 的“code → token”流程，仅负责 JWT 的生成、签名与校验；OAuth2 交互必须用 golang.org/x/oauth2，JWT 用于内部服务间信任传递。
直接说结论：Golang 里 golang-jwt/jwt/v5 不参与 OAuth2 的“code → token”流程，它只负责 JWT 的生成、签名和校验；OAuth2 协议交互必须用 golang.org/x/oauth2，JWT 是你拿到 access_token 后，自己选择用它封装用户信息的可选环节。
OAuth2 流程中，golang-jwt/jwt/v5 到底在哪介入
它不介入授权码交换（Exchange）、不处理 RedirectURL 校验、不管理 state、也不解析服务商返回的原始 JSON 响应。它的唯一职责是：当你决定「自己签发一个内部 JWT 作为会话凭证」时，才用它构造和验证这个令牌。
典型场景是——用户通过 GitHub OAuth2 登录成功后，你的服务不直接透传 GitHub 的 access_token 给下游微服务，而是用 jwt.NewWithClaims 生成一个带 user_id、scope、exp 的新 JWT，再返回给前端。
- OAuth2 负责「信任第三方」（如 GitHub 确认用户身份）
- JWT 负责「内部信任传递」（你自己的服务之间用这个 token 互信）
- 二者是上下游关系，不是替代关系
golang-jwt/jwt/v5 签发 JWT 时必须注意的参数细节
如果你在 OAuth2 回调成功后生成 JWT，这几个字段不能拍脑袋填：
立即学习“go语言免费学习笔记（深入）”；
-
exp必须设为time.Now().Add(...).Unix()，别用time.Now().Add(...).UTC().Unix()—— Go 的Unix()已是 UTC 时间戳，重复转 UTC 会导致过期时间错乱 -
iss（issuer）建议填你自己的服务域名，比如"https://api.example.com"，便于后续审计和多租户隔离 -
aud（audience）若下游服务有明确接收方，应写死为该服务标识（如"order-service"），否则校验时会失败 - 别把敏感字段（如密码哈希、完整邮箱）塞进 payload；
user_id+role+exp足够支撑大多数鉴权逻辑
为什么 Parse 失败却只报 token is invalid 没有具体原因
jwt.Parse 默认只返回一个笼统的 error，实际错误类型被包装了。你需要显式断言才能看到真实问题：
token, err := jwt.Parse(tokenString, keyFunc)
if err != nil {
if errors.Is(err, jwt.ErrTokenExpired) {
// 处理过期
} else if errors.Is(err, jwt.ErrTokenMalformed) {
// 处理格式错误（比如少一段）
} else if errors.Is(err, jwt.ErrTokenInvalidClaim) {
// claim 校验失败（如 aud 不匹配）
}
return
}
常见真因包括：
- 密钥函数
keyFunc返回了空nil，导致签名无法验证 - 用了
HS256签名但传入RS256解析器（算法不匹配） - payload 里写了
nbf（not before），但服务器时间比 NTP 慢了几秒，被判定为“尚未生效”
OAuth2 + JWT 组合下最容易被忽略的吊销难题
OAuth2 提供 revoke 接口能废掉第三方 token，但你自己签发的 JWT 是无状态的——没有中心存储，就无法实时吊销。这意味着：
- 用户点“退出登录”，只能删掉前端 cookie 或 localStorage，但已发出的 JWT 在过期前仍有效
- 若需强制登出，必须引入 Redis 黑名单（存
jti+ 过期时间），并在Parse后额外查一次 - 更轻量的做法是把 JWT 生命周期压到 15–30 分钟，并依赖刷新机制，而非追求实时吊销
别指望 golang-jwt/jwt/v5 自动帮你解决吊销——它连数据库都不碰，这事得你设计存储层和中间件逻辑。
