google oauth2回调需严格匹配authorized redirect uris；github需显式申请"user:email"并单独请求邮箱api；各provider须用独立state防冲突；google需设accesstype: "offline"获取refresh_token，github则无需刷新。
Google OAuth2回调地址400错误：redirect_uri_mismatch
本地开发时最常卡在这一步——Google控制台配置的Authorized redirect URIs和你代码里传给oauth2.Config.AuthCodeURL的state参数无关，但和实际发起跳转时拼出的完整回调地址必须完全一致（协议、域名、端口、路径，连末尾斜杠都不能差）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Go服务跑在
http://localhost:8080，就填http://localhost:8080/auth/google/callback，别写http://127.0.0.1:8080/...或漏掉/callback - 用
url.ParseRequestURI检查你构造的redirect_uri是否合法，尤其注意http不是https时，Google允许但GitHub强制要求https（除非localhost） - 如果用了反向代理（比如Nginx），确保
X-Forwarded-Proto头被正确传递，否则req.URL.Scheme可能仍是http，导致拼出的redirect_uri和控制台不匹配
GitHub OAuth2获取用户邮箱返回空：scope没配对
GitHub默认只返回公开信息（用户名、头像、公开邮箱），要拿到私有邮箱得显式申请user:email scope，且用户授权页会明确列出——很多人只写了user或漏掉冒号。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 初始化
oauth2.Config时，Scopes字段必须包含"user:email"（不是"user"，也不是"email"） - 调用
config.Exchange拿到token后，要用该token单独请求https://api.github.com/user/emails，不是从/user接口里“顺带”取——后者只返回主邮箱（且仅当用户设为公开） - 注意响应是JSON数组，需遍历找
primary: true且verified: true的项，未验证的邮箱即使存在也拿不到
Google与GitHub登录共用同一套OAuth2中间件：state参数不能混用
两个提供商的state参数本质是防CSRF的随机字符串，但如果你用同一个state生成逻辑（比如固定前缀+时间戳），Google和GitHub回调都会打到同一个/auth/{provider}/callback路由，但解析逻辑不同——容易导致token交换失败或用户身份错乱。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个Provider的
AuthCodeURL调用必须传独立state，推荐格式："google_" + base64.RawURLEncoding.EncodeToString(randBytes) - 回调处理函数里先从
state前缀识别来源（strings.HasPrefix(state, "google_")），再用对应Provider的Config实例执行Exchange - 别把
state存session里跨请求用——它本应是一次性、短时效的，存久了反而增加被重放风险
生产环境Token刷新失败：refresh_token只在首次授权时下发
Google默认不返回refresh_token，除非你在oauth2.Config里显式加AccessType: "offline"且用户是首次授权；GitHub压根不支持refresh token，它的access token就是长期有效的（可手动回收）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Google集成必须加
AccessType: "offline"，且第一次授权时用户看到的权限页会多一行“离线访问”，这是必要条件 - GitHub不用考虑刷新，但要注意它的token没有过期时间，务必提供用户主动解绑入口（调用
DELETE /applications/{client_id}/tokens/{access_token}） - 别假设所有Provider都支持refresh——比如GitLab需要额外
prompt=consent参数才能强制返回新refresh_token
真正麻烦的是混合场景：Google token要定期刷新，GitHub token永久有效，数据库里得存两套过期逻辑，而且用户切换登录方式时，旧token的清理时机很容易被忽略。
