OAuth2负责“怎么拿到令牌”，JWT负责“令牌里装什么、怎么验”，二者在Go中分工协作：OAuth2流程终点生成JWT，JWT是其常用承载格式；golang.org/x/oauth2仅提供底层client封装，不处理Web层重定向、state校验、session绑定等细节，需手动实现/login与/callback路由及用户信息映射；JWT签名应据部署结构选HS256（单体/内网）或RS256（微服务/多租户），后者密钥更安全但性能低10–20倍；鉴权中间件易漏exp校验、Bearer前缀剥离、refresh_token机制及密钥轮换支持。
直接上结论：OAuth2 负责“怎么拿到令牌”，JWT 负责“令牌里装什么、怎么验”，二者在 Go 中不是二选一，而是分工协作——OAuth2 流程终点生成 JWT，JWT 是 OAuth2 的常用承载格式。
为什么 Gin/Echo 项目里总要自己写 OAuth2 回调逻辑？
因为标准 OAuth2 授权码流程（Authorization Code Flow）涉及重定向、code 换 token、用户信息拉取三步，Go 生态没有开箱即用的“全链路中间件”。golang.org/x/oauth2 只提供底层 client 封装，不处理 HTTP 路由、session 绑定、错误跳转等 Web 层细节。
- 常见错误现象：
redirect_uri_mismatch（配置的 redirect_uri 和请求时不一致）、invalid_grant（code 被重复使用或过期）、回调后拿不到用户 ID - 必须手动实现的环节：/login → 重定向到第三方授权页；/callback → 接收 code、调用
conf.Exchange()换 token、再用 token 调userinfo接口获取用户数据 - 容易踩的坑：没校验 state 参数防 CSRF；没把第三方返回的 user_id 映射到本地用户表（或创建新用户）；没设置
http.SetCookie写 sessionID 或直接签发 JWT 返回给前端
JWT 签发时该用 HS256 还是 RS256？
看部署结构。单体或可信内网服务用 HS256（对称密钥）够用；微服务或多租户场景必须用 RS256（非对称密钥）——认证服务用私钥签名，各业务服务用公钥验签，避免密钥泄露导致全系统沦陷。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
HS256示例：密钥硬编码在 config 中，jwt.NewWithClaims(jwt.SigningMethodHS256, claims)，适合开发/小项目 -
RS256要求：提前生成 PEM 格式私钥（private.key）和公钥（public.pem），签发时用jwt.SigningKey{Key: privKey, Method: jwt.SigningMethodRS256}，验签时用jwt.Parse(..., func(*jwt.Token) (interface{}, error) { return &pubKey, nil }) - 性能影响：RS256 签验速度比 HS256 慢 10–20 倍，但对单次登录/鉴权无感知；别在高频内部调用中频繁签新 JWT
OAuth2 + JWT 鉴权中间件里最容易漏掉的三件事
很多中间件只做“解析 token → 提取 user_id → 放入 context”，但生产环境会因此出问题。
立即学习“go语言免费学习笔记（深入）”；
- 没检查
exp字段：jwt.MapClaims默认不自动校验过期，必须显式调用token.Claims.(jwt.MapClaims)["exp"]并与time.Now().Unix()比较，或用jwt.Parse(..., jwt.WithValidMethods([]string{"RS256"}))配合自定义KeyFunc在解析时触发校验 - 没剥离 bearer 前缀：从
Authorization: Bearer xxx中提取 token 时，忘了用strings.TrimPrefix(authHeader, "Bearer ")，导致解析失败报square/go-jose: error in cryptographic primitive - 没处理刷新逻辑：OAuth2 access_token 通常短时效（如 1h），但 JWT 自己签发的 token 如果也设太短，前端就得频繁重登录；建议 JWT 设 24h，另配独立 refresh_token（存 Redis + 设置过期），由 /refresh 接口换新 JWT
最易被忽略的其实是密钥轮换——上线后不能永远用同一把私钥。RS256 场景下，得支持多公钥并存（比如 key ID 区分 v1/v2），否则滚动更新时老 token 会批量失效。
