Go HTTP handler panic 后如何区分恢复和连接中断

Go 的 HTTP handler 出现 panic 后，看到“请求失败”并不能直接说明是客户端断开。要先分三层看：同一 handler goroutine 里的 defer recover 可以把 panic 转成业务响应；如果没有恢复，net/http 服务器会在 ServeHTTP 外层接管并记录堆栈，HTTP/1 可能关闭连接，HTTP/2 则重置流；而客户端主动离开时，最可靠的线索是 Request.Context() 被取消以及写响应时返回的错误。

panic、500 响应、Context 取消和 Write 错误不是同一个状态。先确认 panic 发生在哪个 goroutine、响应头是否已经提交，再决定记录“应用异常”还是“请求已取消”。

recover 能处理哪一层 panic，不能处理哪一层？

recover 的关键不是“离 panic 有多近”，而是调用栈和 goroutine 是否相同。下面这个中间件包住 next.ServeHTTP，因此能接住 handler 同步执行期间的 panic：

func recoverHTTP(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if v := recover(); v != nil {
                // 这里仍在处理当前请求的 goroutine 中，才有机会转成 500。
                log.Printf("handler panic path=%s panic=%v", r.URL.Path, v)
                http.Error(w, "internal server error", http.StatusInternalServerError)
            }
        }()

        next.ServeHTTP(w, r)
    })
}

如果 next 启动了一个独立 goroutine，那个 goroutine 的 panic 不会回到这层 recover。需要在 worker 自己的入口设置 defer，或者改成把错误通过 channel 返回给 handler。否则你会误以为“已经有恢复中间件，为什么进程仍然退出”。

没有业务 recover 时，net/http 会怎样处理 panic？

官方 net/http 文档说明，ServeHTTP panic 后服务器会认为影响被限制在当前请求，恢复 panic 并把堆栈写入服务器错误日志；随后按协议关闭网络连接，或向 HTTP/2 发送 RST_STREAM。这不是一个稳定的 JSON 500 响应，所以 API 服务通常仍应在业务边界加恢复中间件。

http.ErrAbortHandler 是特殊用途：用它 panic 可以让客户端看到被中断的响应，同时抑制服务器错误日志中的堆栈。它不等于“客户端已经断开”，也不适合拿来代替普通异常处理。

还有一个常见边界：如果 handler 已经调用 WriteHeader 或写出了 body，再进入恢复分支，http.Error 可能无法撤销已经发出的状态码和数据。恢复代码应该记录“响应是否提交”，不要承诺一定能把线上响应改成完整的 500。

怎么把 panic、响应提交和连接中断分开记录？

耗时处理或流式响应中，应同时观察请求上下文和写入结果：

func stream(w http.ResponseWriter, r *http.Request) {
    for i := 0; i 

对传入服务器请求，官方文档规定其 Context 会在客户端连接关闭、HTTP/2 请求取消，或 ServeHTTP 返回时被取消。因此它适合驱动数据库查询、下游 RPC 和循环退出，但不要把“handler 正常 return”误记成客户端断开。日志中至少保留 path、request ID、是否捕获 panic、是否写过响应以及 context 错误。

线上排查可以按这张表走

常见问题

recover 后一定能返回 500 吗？

不一定。若响应头或 body 已经写出，状态可能已经提交；此时应记录 panic 和响应阶段，避免再声称客户端收到完整的 500。

HTTP/2 的 RST_STREAM 是客户端连接断开吗？

不是。它可能是服务器因 handler panic 主动终止当前流。要结合服务端 panic 日志和客户端上下文状态判断。

为什么外层 recover 接不到 goroutine 里的 panic？

因为 recover 只对同一 goroutine 的 deferred 调用生效。为 worker 单独设置恢复边界，或让 worker 返回 error，由 handler 统一决定响应。

相关依据

行为细节可查阅 Go 官方 net/http 包文档中的 Handler、Request.Context、ErrAbortHandler 和 ResponseWriter 说明；排查时以实际使用的 Go 版本和 HTTP 协议为准。