HTTP/2中recover必须绑定到每个流的goroutine，因每个请求流独立运行在goroutine中，仅当前goroutine内defer recover有效，需在中间件ServeHTTP最外层添加，且须检查响应头是否已写入以避免重复WriteHeader错误。
HTTP/2流处理中recover必须绑定到每个流的goroutine
Go的http.Server在启用HTTP/2后，每个请求流（stream）仍运行在独立goroutine中，recover只对当前goroutine有效——这意味着你不能在main或init里加defer recover()，也不能指望一次注册覆盖所有流。必须确保每个流处理入口都有自己的defer + recover逻辑。
标准库ServeHTTP中recover的正确位置
如果你直接使用net/http并启用了HTTP/2（默认开启，只要TLS配置正确），recover只能放在中间件的ServeHTTP方法内，且必须在调用next.ServeHTTP(w, r)之前：
-
defer语句必须写在handler闭包最外层，不能嵌套在子函数里 - 不能用
http.HandleFunc注册裸函数，否则无法插入recover逻辑 - 如果
w已写入响应头（如下游提前调用w.WriteHeader(200)），recover分支里再调w.WriteHeader(500)会触发http: multiple response.WriteHeader calls错误
示例代码片段：
func recoverMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
// 先检查是否已写入响应头
if !w.Header().Get("Content-Type") == "" {
// 已写入？跳过或记录告警
log.Printf("panic in %s but response already written", r.URL.Path)
return
}
w.WriteHeader(http.StatusInternalServerError)
json.NewEncoder(w).Encode(map[string]string{
"code": "500",
"message": "Internal Server Error",
})
log.Printf("PANIC: %v\n%s", r, debug.Stack())
}
}()
next.ServeHTTP(w, r)
})
}
使用第三方路由器（chi/gorilla/mux）时recover的陷阱
这些库的Recoverer中间件默认不检查响应头状态，HTTP/2下更容易触发重复WriteHeader。尤其要注意：
立即学习“go语言免费学习笔记（深入）”；
-
chi.Middleware.Recoverer在panic后直接调http.Error，若下游handler已写header，就会panic二次崩溃 -
gorilla/mux没有内置recover，需手动包装http.Handler，不能只包装http.HandlerFunc - 若使用
go-zero等框架，确认server.Use()注册顺序：recover中间件必须排在业务handler之前，且不能被其他中间件提前写响应
HTTP/2特有的panic场景与recover失效点
HTTP/2流级错误（如stream reset、flow control violation）通常由底层net/http自动处理，不会触发用户代码panic；但以下情况仍会导致recover失效：
- 在
http.ResponseWriter上调用Flush()后panic：此时响应头已发，recover分支写500会失败 - 异步goroutine中发生panic（如
go func(){...}()）：主流goroutine的recover完全捕获不到 - 使用
h2c（HTTP/2 without TLS）时，某些客户端异常断连可能绕过标准中间件链
真正关键的不是“怎么配”，而是意识到：HTTP/2没改变recover的作用域，它只是让流更细粒度了——每个流仍是独立执行单元，该加recover的地方，一个都不能少，也一个都不能加错位置。
