github和google oauth2常见问题根因是redirect_uri不匹配或state校验缺失；须严格配对平台设置与代码url，用session存state，golang.org/x/oauth2需手动设正确endpoint和scope，用户信息获取需按平台差异处理。
github OAuth2 授权 URL 构造不对，回调 404 或 state mismatch
根本原因通常是 redirect_uri 在 GitHub OAuth App 设置里没配对，或代码里拼写不一致（比如少了个 /、用了 http 而不是 https）。GitHub 对 redirect_uri 校验极严格，必须完全匹配，连末尾斜杠都不能错。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在 GitHub Settings → Developer settings → OAuth Apps 里确认
Authorization callback URL填的是你后端实际接收回调的完整地址，例如https://yourdomain.com/auth/github/callback - Go 侧用
url.Values拼授权 URL，别手拼字符串；state必须存到 session 或 signed cookie，不能放 query 里传回来（防 csrf） - 回调 handler 开头就校验
state是否和之前发出去的一致，不一致直接 400；code只能用一次，用完即弃
google OAuth2 Token exchange 返回 invalid_grant 或 bad request
常见于 code 过期（Google 默认 10 分钟）、重复使用、或 redirect_uri 和 Google Cloud console 中注册的不一致。注意：Google 要求 redirect_uri 必须和申请 code 时用的完全相同，且必须是白名单里的——哪怕只是端口不同（localhost:8080 ≠ localhost:3000）也会失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Google Cloud Console 的 OAuth 同意页面必须发布（否则只允许测试用户），且
Credentials → OAuth client ID下的Authorized redirect URIs要精确填写，包括协议、域名、端口、路径 - 调
https://oauth2.googleapis.com/token时，用application/x-www-form-urlencoded，body 里必须含code、client_id、client_secret、redirect_uri、grant_type=authorization_code - 别用
net/http自己拼 json body——Google 不认，会返回invalid_request
Go 的 golang.org/x/oauth2 包怎么设 scope 和 endpoint 才不踩坑
GitHub 和 Google 的 OAuth2 实现细节差异大：golang.org/x/oauth2 提供通用框架，但每个服务商的 AuthURL、TokenURL、默认 Endpoint、支持的 scope 都得手动指定，不能全靠包内置常量。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- GitHub 用
github.Endpoint（它已预设好 AuthURL/TokenURL），但scope要显式传，比如[]String{"user:email", "read:user"}；Google 则必须用google.Endpoint，且scope推荐用google.UserinfoEmailScope和google.UserinfoProfileScope -
oauth2.Config.RedirectURL必须和你在平台注册的完全一致；它不参与签名，但影响 token exchange 成败 - 别把
Config当全局单例反复复用——Config.Client()返回的 client 是无状态的，但如果你在中间件里动态改Config.RedirectURL，要注意并发安全
拿到 access_token 后怎么安全获取用户信息（避免 401 或 rate limit）
GitHub 和 Google 的用户信息接口权限模型不同：GitHub 的 /user 需要 token 有对应 scope 且未过期；Google 的 https://www.googleapis.com/oauth2/v2/userinfo 则依赖 token 有效性，且调用频次受项目级配额限制。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- GitHub 请求
https://api.github.com/user时，header 必须带Authorization: Bearer <access_token></access_token>；若返回 401，先检查 token 是否被 revoke，再看 scope 是否覆盖了需要的字段（比如没user:email就拿不到邮箱） - Google 请求 userinfo 接口时，推荐用
google.UserInfoService（来自google.golang.org/api/oauth2/v2），它自动处理 token refresh 和 Error retry；别自己写 HTTP client 去调 - 无论哪家，用户数据都应做最小化缓存（比如只存
id、email、avatar_url），别把原始响应整个存 DB；token 本身不要落库，除非你要做后台刷新
最易被忽略的是：GitHub 的 email 字段默认不公开，即使你有 user:email scope，也得额外请求 https://api.github.com/user/emails 并解析 primary=true 的条目；Google 则在 userinfo 里直接返回 verified_email，但前提是用户授权时勾选了邮箱——这两处逻辑不一致，很容易漏处理。