Beego集成GitHub OAuth2必须手动使用golang.org/x/oauth2，严格完成state校验（存取session、恒定时间比对）、redirect_uri逐字节一致、token换取、API请求带Bearer头四步；漏一即静默失败。
Beego 本身不提供 OAuth2 封装，GitHub 登录必须手动对接 golang.org/x/oauth2，关键不是“能不能做”，而是 state 校验、redirect_uri 一致性、token 换取和用户信息解析这四步漏一不可。
state 参数必须存 session 且严格比对
GitHub 的 OAuth2 流程要求防止 CSRF，state 不是可选字段。Beego 的 c.SetSession("oauth_state", state) 和 c.GetString("state") 必须成对出现，且不能用 cookie 或 query 直接传参替代 session 存储。
- 常见错误：回调时只校验 URL 中的
state参数，没查 session，导致攻击者伪造 code + state 绕过验证 - Beego 默认 session 引擎是 file，若部署多实例需切到 redis 或 memcache，否则 session 可能丢失
-
state建议用 crypto/rand 生成 32 字节随机值，不要用时间戳或简单字符串
redirect_uri 必须与 GitHub App 设置完全一致
GitHub 后台配置的 Authorization callback URL 和 Beego 路由中拼出的回调地址（如 /auth/github/callback）必须一字不差，包括协议、域名、路径、末尾斜杠。
GInstall OneClick — 一键安装 GitHub 项目：规划、克隆、安装 Node 依赖、运行开发脚本。适用于想要获取 GitHubNode.js 项目的用户。
- 典型坑：本地开发用
http://localhost:8080/auth/github/callback，但 GitHub App 配了http://localhost:8080/auth/github/callback/（多一个/），结果返回redirect_uri_mismatch - Beego 中构造授权 URL 时，
conf.AuthCodeURL(state, oauth2.SetAuthURLParam("login", ""))的参数不能遗漏，否则 login 提示可能不生效 - 生产环境务必用 HTTPS，GitHub 不接受 HTTP 的 callback URL（localhost 除外）
用 token 换用户信息要带 Authorization Header
拿到 *oauth2.Token 后，必须用 conf.Client(ctx, token) 构造带 Bearer Token 的 HTTP client，再请求 https://api.github.com/user，直接用普通 http.Client 会返回 401。
- 常见错误：调用
http.Get("https://api.github.com/user")而没设置 header，结果拿到空响应或 401 - GitHub 返回的 JSON 包含
login（用户名）、avatar_url、email（可能为空，需额外 scopeuser:email） - 如果需要组织信息或仓库列表，得额外申请
read:org或reposcope，并在Scopes列表里声明
Beego Controller 里别碰阻塞式 IO，尤其别用 fmt.Scan
示例代码里 fmt.Scan(&code) 是命令行调试写法，放进 Beego HTTP handler 会导致整个 goroutine 卡死——HTTP 请求不会等你手动输 code。
- 正确做法：授权跳转走
c.Redirect()到 GitHub；回调路由收code和state后立即处理 - token 换取和 API 请求都应在 handler 内同步完成，不要起 goroutine 后异步写 session，session 写入必须在
c.ServeJSON()或c.TplName前完成 - 错误日志建议打到 Beego 的
beego.Error()，别只靠fmt.Println，否则线上无法排查
最易被忽略的是 redirect_uri 的末尾斜杠和 session 引擎一致性——前者让整个流程在 GitHub 侧就失败，后者让 state 校验在 Beego 侧失效，两者都会导致静默登录失败，连错误响应都收不到。
