OAuth2回调中recover必须放在handler内层defer中，因net/http仅默认捕获panic并返回500，无法定制响应；中间件统一recover易漏panic、混淆错误类型且可能重复写响应头。
OAuth2回调函数里直接加recover没用
因为 golang.org/x/oauth2 不处理路由，/callback 是你手动注册的 HTTP handler，而 Go 的 HTTP server 在调用 handler 时，本身就在一个 goroutine 里运行——如果这个 handler panic 了，它只会影响当前请求，不会让整个服务挂掉。但如果你没做 recover，panic 会直接被 net/http 捕获并打印堆栈到日志，前端看到的是 500 错误，且无上下文提示。
所以 recover 要加在你自己的 handler 函数内部，而不是包级或中间件里“统一加”——后者容易漏掉调用栈层级，或者恢复了却没返回有意义的响应。
正确的 defer + recover 写法（带错误透传）
必须把 recover 放在 handler 函数最外层的 defer 里，并确保能返回 HTTP 状态和用户友好的提示。常见错误是 recover 后直接 return，忘了写 w.WriteHeader() 或 json.NewEncoder(w).Encode()。
- recover 只在
defer中有效，且必须在 panic 发生的同一 goroutine 中执行 - handler 函数里不能用命名返回值传递 error，得手动控制响应体和状态码
- 建议用
runtime/debug.Stack()记录完整堆栈，但别直接返回给前端（含敏感路径）
示例：
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
立即学习“go语言免费学习笔记（深入）”；
func oauthCallbackHandler(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in /callback: %+v\n%v", r, debug.Stack())
http.Error(w, "Authentication failed, please try again", http.StatusInternalServerError)
return
}
}()
state := r.URL.Query().Get("state")
if !validateState(state) { // 自己实现的校验逻辑
http.Error(w, "Invalid state parameter", http.StatusBadRequest)
return
}
token, err := conf.Exchange(r.Context(), r.URL.Query().Get("code"))
if err != nil {
http.Error(w, "Failed to exchange code for token", http.StatusUnauthorized)
return
}
userInfo, err := getUserInfo(token.AccessToken)
if err != nil {
http.Error(w, "Failed to fetch user info", http.StatusBadGateway)
return
}
// ... 映射本地用户、签发 JWT 等
}
为什么不能在中间件里统一 recover
Go 的 net/http 默认对每个 handler panic 都做了 recover（见 server.go 中的 serveHTTP 调用链），但它只负责打印日志+返回 500，不提供定制化响应逻辑。你写一个中间件 wrapper 套在所有 handler 外面，看似“统一”，实际有三个坑：
- 中间件里的 defer 执行时机晚于 handler 内部的 defer，可能错过某些 panic（比如 panic 发生在
conf.Exchange()内部且它自己没 recover） - 无法区分是 OAuth 流程出错（如
invalid_grant）还是代码 bug（如空指针），统一返回 500 会让前端无法重试或提示用户 - 如果中间件 recover 后继续执行 handler，可能导致重复写 response（触发
http: multiple response.WriteHeader calls）
容易被忽略的 panic 场景
OAuth2 回调里最常被忽视的 panic 来源不是网络错误，而是数据解析和类型断言：
-
r.URL.Query().Get("code")返回空字符串，传给conf.Exchange()不 panic，但后续token.Extra("id_token").(string)会 panic —— 因为Extra返回interface{}，类型断言失败直接 panic - 第三方
userinfo接口返回字段缺失（如微信不返回email），你代码里写user.Email就 panic（如果user是 struct 且字段未初始化） -
json.Unmarshal遇到非法 JSON 不 panic，但如果你用map[string]interface{}解析后再强制取值，比如m["data"].(map[string]interface{})["id"]，任意一层为nil或类型不符都会 panic
这些地方比 recover 更值得加防御性检查：用 ok 判断类型断言，用指针字段 + if user.Email != nil，用结构体 tag 控制 json 解析容错。
