Revel 框架不内置 OAuth2 客户端支持，因其设计聚焦路由、控制器等核心功能，未包含身份认证层；推荐用 goth 库结合 revel.Session 手动接入，微信等非标平台需单独适配。
Revel 框架本身不内置 OAuth2 客户端支持，直接用 revel 做第三方登录必须自己封装流程或引入外部库——这不是配置开关的问题，而是框架设计决定的。
为什么 Revel 没有开箱即用的 OAuth2 支持
Revel 是一个强调“约定优于配置”的 Go Web 框架，但它的核心聚焦在路由、控制器、模板和中间件生命周期，不包含身份认证层。OAuth2 流程（重定向、state 管理、token 交换、用户信息拉取）涉及大量 HTTP 跳转、session 维护和 provider 差异处理，这些被有意留给上层业务或第三方库实现。
- 官方未提供
revel.Auth或类似模块 -
revel.Session只负责基础 session 存储，不自动绑定 OAuth state 或 code - 没有 provider 预设（如 GitHub、微信等），每个平台的
auth_url、token_url、响应字段都得手动处理
推荐用 goth + revel.Session 手动接入
goth 是目前 Go 生态中维护最活跃、provider 最全的 OAuth2 库（支持 GitHub、Google、GitLab、Twitter、微信开放平台等），它不依赖特定 Web 框架，正好补足 Revel 的缺失。
- 用
goth.UseProviders(...)注册 provider，注意传入的redirectURL必须与你在第三方平台配置的回调地址完全一致（包括 http/https、端口、路径） - 在 Revel controller 中调用
goth.GetProvider("github").BeginAuth(r.Request)获取重定向 URL，然后用r.Redirect(...)跳转 - 回调 endpoint（如
/auth/github/callback）里调用goth.CompleteAuth(r.Request)，它会自动校验state并请求access_token - 拿到
user后，把user.UserID和user.AccessToken存进r.Session.Set("user_id", ...)，别存原始refresh_token——goth默认不返回它，且多数 provider（如 GitHub）根本不发
微信登录等需要特殊处理的 provider
微信开放平台（Weixin）和微信公众平台（WeixinMP）不是标准 OAuth2 实现：它们的 access_token 是平台级凭证、需服务端长期缓存；而用户级 openid 是通过 js_code 换取的，且不返回 refresh_token。
- 别用
goth的默认 Weixin provider（已过时），改用netnr.Login的 C# 封装思路反推：自己写GET /auth/weixin/authorize构造带appid、redirect_uri、scope、state的 URL - 回调里用
http.Post向https://api.weixin.qq.com/sns/oauth2/access_token提交appid、secret、code，解析 JSON 响应中的openid和access_token -
state必须用r.Session.Set("oauth_state", xxx)存，回调时比对，否则有 CSRF 风险 - 微信的
access_token有效期 2 小时，且调用量有限制，不能当用户 token 用 —— 它只是换取openid的临时凭证
refresh_token 怎么办？
绝大多数面向用户的 OAuth2 provider（GitHub、Google、GitLab）在首次 token 交换时**不返回** refresh_token，除非你显式申请 offline_access scope 且 provider 支持。微信、微博、钉钉等国内平台基本不返回。
- 不要假设
refresh_token一定存在；检查响应 body 是否含"refresh_token"字段再存 - 如果要用，必须在第一次请求 token 时带上
access_type=offline（Google）或prompt=consent（部分平台），否则只给短期access_token - 存
refresh_token到数据库时，务必加密（如用golang.org/x/crypto/nacl/secretbox），别明文落库 - Revel 的
Session默认基于 cookie，不适合存refresh_token—— 它生命周期长、敏感度高，必须服务端存储
真正麻烦的不是跳转和回调，而是每个 provider 对 scope、response_type、error 格式、字段命名（user_id vs id vs sub）的细微差别，以及微信这类非标实现的适配成本。别指望“一套代码打天下”，provider 越多，分支逻辑越重。
