OAuth授权失败时err为nil但token为空，因客户端仅在网络错误时设err，而服务端4xx响应被当作成功解析；需手动检查HTTP状态码和token是否为nil。
OAuth授权失败时，err 为什么总是 nil 但实际没拿到 token？
Go 的 OAuth2 客户端（比如 golang.org/x/oauth2）在交换 code 换 token 失败时，常常不返回错误，而是把 HTTP 错误响应体当正常响应解析，导致 token 为 nil，err 也是 nil —— 这是默认行为，不是 bug。
根本原因是：它只在底层网络出错（如连接超时、DNS 失败）时才设 err；而服务端返回 400 Bad Request 或 401 Invalid client 这类响应，会被当成“成功响应”交给 JSON 解析器，解析失败才设 err。但很多错误响应其实是合法 JSON（比如 {"error":"invalid_grant"}），解析成功，err == nil，token == nil 却被静默忽略。
- 检查
token是否为nil，不能只看err - 手动读取响应体做二次判断：用
ctxhttp.Do或自定义http.Client拦截响应状态码 - 示例关键逻辑：
resp, err := client.Do(req) if err != nil { return nil, err } defer resp.Body.Close() if resp.StatusCode < 200 || resp.StatusCode >= 300 { body, _ := io.ReadAll(resp.Body) return nil, fmt.Errorf("token exchange failed: %d %s, body: %s", resp.StatusCode, resp.Status, string(body)) }
用 oauth2.Config.Exchange 时，ctx 超时没生效？
常见现象：传了带 context.WithTimeout 的 ctx，但网络卡住十几秒才返回，超时没触发。这是因为 Exchange 内部用的默认 http.Client 没配 Timeout，只依赖 context 取消 —— 而某些底层 TCP 握手或 TLS 协商阶段，context 取消信号无法及时中断。
-
oauth2.Config的Client字段必须显式设置，否则走全局http.DefaultClient - 正确做法：构造带
Timeout的 client，并确保 transport 也设IdleConnTimeout和TLSHandshakeTimeout - 别只信
context.WithTimeout，HTTP 层超时要双保险 - 示例：
client := &http.Client{ Timeout: 10 * time.Second, Transport: &http.Transport{ TLSHandshakeTimeout: 5 * time.Second, }, } config.Client = client
刷新 token 失败后，oauth2.ReuseTokenSource 会静默降级回原始 token？
很多人用 oauth2.ReuseTokenSource(oldToken, refreshTokenSource) 做自动续期，但遇到 refresh 失败（比如 refresh token 已失效），它不会 panic 或报错，而是直接返回旧 token —— 即使它已过期。下游 API 调用立刻 401，问题被掩盖到更晚环节。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
-
ReuseTokenSource.Token()在 refresh 失败时，会原样返回旧*oauth2.Token，不校验Expiry - 必须自己包装一层：调用前先检查
token.Expiry.Before(time.Now())，过期则强制走 refresh 并处理失败路径 - 不要依赖
ReuseTokenSource的“智能”，它只复用，不验证 - 生产环境建议弃用
ReuseTokenSource，改用显式管理 token 生命周期的封装
自定义 oauth2.TokenSource 时，ErrNoRefreshToken 怎么安全透出？
当用户首次授权后只拿到 access token（没给 refresh token），后续任何 refresh 尝试都会触发 oauth2.ErrNoRefreshToken。这个 error 是导出的，但直接返回给上层容易被忽略 —— 比如日志里只打印 "no refresh token"，没人知道该引导用户重新登录。
-
oauth2.ErrNoRefreshToken是一个哨兵 error，可用errors.Is(err, oauth2.ErrNoRefreshToken)精确判断 - 别用
strings.Contains(err.Error(), "refresh")这种脆弱方式 - 在 handler 层捕获后，应明确返回用户可操作的状态（如
401 + {"reason": "refresh_token_missing"}），而不是泛化成 500 - 注意：某些 IDP（如 GitHub）在 scope 不含
offline_access时，压根不发 refresh token —— 这属于配置问题，不是代码异常
事情说清了就结束。最常漏掉的是：token 交换后不检查 token == nil，以及以为 context 超时能覆盖所有网络阶段。
