golang.org/x/oauth2仅提供token交换等底层函数，不处理/login和/callback路由，需手动实现state校验、conf.Exchange()调用、userinfo获取及本地用户映射，并注意redirect_uri匹配、JWT签发选型（HS256/RS256）、JWKS动态加载、时间同步及鉴权中间件的Bearer剥离、exp/iss/aud校验等关键细节。
golang.org/x/oauth2 只负责换 token，不处理回调路由
你不能指望 golang.org/x/oauth2 自动帮你注册 /login 和 /callback 路由，它只提供 conf.Exchange() 这类底层函数。Web 层逻辑必须自己写。
常见错误现象：redirect_uri_mismatch（配置的 redirect_uri 和实际请求不一致）、invalid_grant（code 被重复使用或已过期）、回调后拿不到用户 ID。
- 必须手动实现
/login：生成随机state、存入 session 或短期缓存、重定向到第三方授权页 - 必须手动实现
/callback：校验state防 CSRF、调用conf.Exchange()换 token、再用 token 请求 userinfo 接口拉取用户数据 - 拿到第三方 user_id 后，需映射到本地用户表（查库 or 创建新用户），不能直接当成本地 ID 用
- 签发 JWT 前，务必设置
exp字段；返回给前端时，建议用http.SetCookie写 HttpOnly cookie，或直接返回 JSON 中的access_token字段
JWT 签发选 HS256 还是 RS256？看部署结构
单体或内网服务用 HS256 就够了；微服务或多租户场景必须用 RS256——不是“更安全所以更好”，而是密钥泄露风险不可接受。
HS256 示例：jwt.NewWithClaims(jwt.SigningMethodHS256, claims)，密钥硬编码或从环境变量读取，简单高效。
立即学习“go语言免费学习笔记（深入）”；
RS256 要求提前生成 PEM 格式私钥（private.key）和公钥（public.pem）：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 签发时用私钥：
jwt.SigningKey{Key: privKey, Method: jwt.SigningMethodRS256} - 验签时用公钥：
jwt.Parse(..., func(*jwt.Token) (interface{}, error) { return &pubKey, nil }) - 别把公钥硬编码进代码；网关或服务启动时应从文件或 JWKS 端点动态加载
性能影响真实存在：RS256 签验速度比 HS256 慢 10–20 倍，但登录/鉴权单次操作无感知；切忌在高频内部 RPC 中频繁签新 JWT。
网关层 JWT 自校验必须配对 JWKS，别硬编码公钥
如果网关用的是 JWT 自校验（而非 OAuth2 Token Introspection），就必须让网关能定期拉取公钥，否则密钥轮换后所有请求都会失败。
常见错误现象：授权服务器更新了私钥，但网关仍用旧公钥验签 → 全量 401 Unauthorized；日志里反复出现 token is invalid 却查不出原因。
- 授权服务器必须暴露标准 JWKS 端点，如
https://auth.example.com/.well-known/jwks.json - 网关配置必须用
jwk-set-uri（如 Spring Boot 的spring.security.oauth2.resourceserver.jwt.jwk-set-uri），而不是public-key属性 - 若用本地文件路径（如
public-key-location: classpath:public.pem），密钥轮换就得重启网关，生产环境不可行 - 注意系统时间差：网关与授权服务器时间偏差超过 60 秒，
exp校验就会失败，不是 bug，是安全设计
鉴权中间件最容易漏掉的四件事
写一个 AuthMiddleware 很快，但上线后出问题往往就卡在这几个点上。
- 没剥离
Bearer前缀：从Authorizationheader 取值时，忘了用strings.TrimPrefix(authHeader, "Bearer ")，导致解析失败 - 没校验
exp字段：jwt.Parse默认不校验过期，必须显式传入jwt.WithValidMethods和自定义Claims类型，或用VerifyExpiresAt钩子 - 没验证
iss和aud：攻击者伪造一个合法签名的 JWT，但iss指向其他认证服务，aud不匹配当前服务，应拒绝 - 没处理 refresh_token 机制：access_token 过期后，前端该用 refresh_token 换新 token，而不是重新走 OAuth2 流程；这个逻辑通常不在中间件里，但得预留接口和存储支持
最麻烦的其实是密钥轮换和 token 吊销——JWT 天然无状态，也就天然难吊销。短生命周期 + Redis 黑名单 + refresh_token 三者得配齐，缺一不可。
